On Thu, 2004-09-16 at 06:28, Mar Matthias Darin wrote: > Fajar A. Nugraha writes: > > > Do you have any suggestion as to how to get back the free()d memory? > > Will (borrowing Apache's way) using a prefork-kind of daemon, with limited > > lifetime > > for each child, be better (in sense of memory management) than the current > > thread implementation? Or perhaps limiting the lifetime of each thread > > sufficient? > > From experience with pthreads and Linux v2.4, pthreads was a royal pain. I > initially used threads as a method of a limited lifetime model for my > firewall design... I kept getting unusual and unpredictable segfaults. The > process would run anywhere from 2 days to several months, then for no > appearent reason,segfault in a routine that had been tested a thousand times > under high stress conditions and not failed.
Such things are generally due to memory usage bugs in the code, they just don't trigger very often. My pthread'ed web proxy has been running very stable on RH 6.2 on kernel 2.2.19) for a very long time, current stats: connections(24104670) requests(54869840) threads(4/24) [The threads stat means there are 24 worker threads started, and 4 of them are currently actively doing something useful at this moment in time - in this model, all networking is non-blocking, so threads don't wait for network I/O - this means that the churn rate for threads is very high, while the actual number of threads remains relatively low.] > > After moving to fork() and named pipes, the same code hasn't broken once in > nearly a year of hard testing. My tested often included 10 or more icmp > floods of at least 65535 packets. I drove my load to 240 during the test... > > Now the forked process uses and frees memory thousands of time per second > with no issue... > > Pthreads work well for light duty non-daemon processes... If its heavy duty It depends how good your model and implementation are in my experience. -trog
signature.asc
Description: This is a digitally signed message part
