A month or two ago there was some discussion on the list about the memory footprint of slon.
I've done some investigating. slon is multi-threaded. For each remote database that the slon instance talks to there will be 2 threads (a remote listener and a remote worker) plus about 4 threads for 'local' stuff. By default on Linux pthread_create gives each thread a stack size controlled by the RLIMIT_STACK setting that can be viewed/adjusted by running 'ulimit -s'. On my ubuntu x64 system the default value for this is 8 megs per thread (why? I have no idea). If I reduce this to 1024 the memory footprint (VmData in /proc/$pid/status ) goes from 14800kb to around 76724kb I see a few choices 1) We can have slon explicitly request a more reasonable thread stack size before it creates threads (pthreads has API calls for this). I'm not 100% sure what the best value for this would be for all platforms but slon tends to be pretty good about not storing large values on the stack 2) We can document this and tell sysadmins/DBA's that are concerned about the slon memory footprint to use their OS's facilities (ie ulimit -s before invoking slon) to adjust how much stack each thread. The argument for 1 is that the slony development team has a better sense of how much stack memory slon threads take, and we might even discover that different threads types of stack memory requirements (I doubt the different slony thread types will very much in stack usage) The argument for 2 is that the OS is already providing facilities to tune this and we should leave it tunable through those. Thoughts? (Even with a 1024kb stack size total memory usage for a 5 database cluster still seems higher than I would like to see) -- Steve Singer Afilias Canada Data Services Developer 416-673-1142 _______________________________________________ Slony1-general mailing list [email protected] http://lists.slony.info/mailman/listinfo/slony1-general
