Hi Sergei, > If I put DEBUG="0", then everything runs ok. > BTW, nobody here succeeded to terminate the > update_svn_and_test.pl script with DEBUG="1".
strange thing, one thing that comes to my mind is that OpenXPKI will execute substantially more code than with debug switched off. > Alex, how much memory do you have in your testing host? build0.cynops.de sometimes migrates between two physical hosts, one having 1 GB RAM, the other 512 MB RAM. Currently it lives on the weaker system. Alex' development system has 2 GB physical RAM, same for mine. > (2) request for external agent (e.g. database) sometime does not > check for timeout, nor for communication error report. > Looks like we adopt a hypothesis that once established connection > to the database (usually this is checked during initialization), > lasts forever and we do not need to check if it works in real time? the general idea is that requests either block or generate an error. This may cause the server timeout to trigger, of course. > What happens if several unserved requests go into > the same socket, while openxpki thinks that they are meant for > the different databases sleeping in the swap? Who will serve what > after awakening? Maybe we should take care ourselves > and build a special queue for requests going to the socket? The forking policy is determined by the Net::Server class. We could try to use a differnt personality to influence its behaviour, though. > Reason B. A single idle PostgreSQL server easily eats 15 MB of memory. > When talked by the openxpki server it forks and eats up to 100 MB. > Do we agree, that if we want to serve 10 users simultaneously, > we need to have 1 GB of memory for databases only, not counting > other important servers? > > Say direct observation via "top" shows that openxpki server > eats up to 100 MB of memory per logged in user. > > Maybe somebody knows a more economical > and clever way how to deal with a database, which serves multiple > simultaneous user requests? IMO having multiple database connections should be no problem for a modern database system. When forking a process, the kernel will normally apply a copy-on-write policy on the variable data. The program code should not be physically duplicated by a fork, I'd expect the kernel to share the code between forked instances. So even if you see multiple processes eating up 100 MB each, I'd expect a real physical memory usage of much less. Alex and I will discuss this and follow up soon. cheers Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
