I think I do not confuse heavy weight processes and light weight proccesses what LinuxThreads are by definition. And still the LinuxThreads follow the same schema of assignment of processNumbers as heavy weight processes do. I was irritated at the first glance from differences in the default behaviour of the "ps" command. On my RH7.2 (ps in procps-2.0.7-11) threads are listed by default, e.g. by "px -lax", while on RH9.0 (procps-2.0.11-6) they are not.
I have in mind -in terms of resource consumption- how expensive it is to have newpki running. We have to be aware such certification/revokation requirements only happen every <n>'th week, at least in the newpki auditory. We are not under the top100 companies. I hear my administrator saying to kick off some what apparently misbehaves, bangs into the system log, secretly creates bulks of data, creates permanent traffic on the LAN, but is nearly never utilized. I say, on the other hand this is beta3 and the rest of newpki is promising. What threatens me is your remark on coming non-compatible structures. Assuming newpki beta3 gets improvements, do you plan to provide a data migration tool from beta3 to an stable release ? ----Urspr�ngliche Nachricht----- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von Fr�d�ric Giudicelli Gesendet: Freitag, 30. Januar 2004 16:18 An: [EMAIL PROTECTED] Betreff: Re: AW: Many instances of newpki-server running [EMAIL PROTECTED] wrote: > Yes, I do agree regarding the threads spawned. The kernel assigns about > 2MB -stack space- to every thread upon it's creation. Further, because (as I > took from the link below) every thread can see the stack of any neighbour, > this necessarily means that the total of all stacks must be present at any > time. The identical VSZ for the threads is an indication here. The doc you read is outdated, the default is 8MB of stack. > Btw : my Oracle shows such effects. It seems to pull gigantic amounts for > each thread. But this is a misinterpretation. > > --------- > > However and regrettably, for my newpki_server the case is different. There > are no <n> LinuxThreads. The newpki_server spawns exactly 1 thread. This one > pulls 700MB and more. If there were more threads, I would see that in > ps -lax. According to your demo program and the docu below generally under > Linux any thread is treated as a heavy weight procces and gets a > processNumber assigned. Your are confusing heavy weight and light weight, NewPKI doesn't spawn other instances of itself, it creates threads, if you don't beleive me look into "Includes/newpki_thread.cpp". I can garantee you, newpki do create those threads, I happended to have written the code :) ps -lax doesn't show you the threads, only the spawned processes, to actually see the threads in a tree sorting: ps axumf is the right command. Once again, newpki doesn't use more than 10MB or RAM, install it under windows, and you will see. The VSZ is irrelevant because of pthread. I don't understand what the problem is, didn't you see the problem with the test program ? > Because its not, I conclude there must be something other under the hood. > > I find this discussion on "bug or feature" quite relevant. At least for > myself it will guide my decision to set newpki_server productive or not. Well, it's a beta version, I highly advise you not to install it in production, because between each beta (because of all the structures changes) you have to remove the databases, and resinstall the whole PKI. In the stable versions, there will be an automatic upgrade process. -- Fr�d�ric Giudicelli http://www.newpki.org _____________________________________________________________________ NewPKI http://www.newpki.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] _____________________________________________________________________ NewPKI http://www.newpki.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
