Re: trick/tips for finding memory leaks
On Sun, 25 Nov 2007 20:16:00 -0500 Sam Carleton [EMAIL PROTECTED] wrote: Thanks to the performance tools of my OS I have confirmed that somewhere in my Apache module there is a memory leak. Are there any tips or tricks out there for find memory leaks in an Apache module? Run inside gdb as a single process, not forking any background processes, -X i think. Then step through your code to see where the leak is. Generally speaking, if you're using apr routines then they should handle the memory resources for you, there should be little need for allocating on the heap. -- The 28.8 frame relay to the Netapp is smelling funky because of All your base are belong to us. Sun Microsystems is havin' a smoke. :: http://www.s5h.net/ :: http://www.s5h.net/gpg.html signature.asc Description: PGP signature
Re: performance vs development time
On Sun, 25 Nov 2007 21:32:13 -0500 Sam Carleton [EMAIL PROTECTED] wrote: With this memory leak in my simple Apache module, I am considering rewriting the whole module. Right now there are two files small files that the module reads every time. One is a small (less then a 1K) configuration file and the other is a small (1K ~20K) xml file. In the rewrite, I am considering caching the data in these files and reading them only if they are changed. The question though is: Considering how small these files are, will the performance gains be worth the extra development time? Another option would be to switch from using libxml2 to expat for the XML parsing. Oh, what type of load is the server under? The server is driving a kiosk system where there are normally a hand full of kiosk but there could be as many as 100 under very heavy use. If it's a kiosk system then it's not really going to matter how you're processing that as the main bottle neck is a human, so you can probably ignore the fact that it's in memory cache. If you want to store the file in memory though, put a void * in your module's .c file, outside of the module routines, so that it's defined at initialisation. Then in your init routines allocate the memory for it. The trouble that you might find yourself in is how to lock this pointer when the file changes AND the memory is being read/written by concurrent processes. For this reason I suggest that you stick to reading the data on access from disk. If disk IO is a problem then put the file on the RAM disk, where there is going to be little difference between having the data read at module run time or from memory - some file system operations are atomic, so you don't need to worry so much. HTH. -- The 28.8 frame relay to south lata is unreliable because of Bernard Shifman threatening to sue. RedHat is selling their dialup customers to Earthlink. :: http://www.s5h.net/ :: http://www.s5h.net/gpg.html signature.asc Description: PGP signature
Re: performance vs development time
Am Sonntag, den 25.11.2007, 21:32 -0500 schrieb Sam Carleton: In the rewrite, I am considering caching the data in these files and reading them only if they are changed. The question though is: Considering how small these files are, will the performance gains be worth the extra development time? No. A decent operating system will keep the files in memory unless they are changed anyway. You could have the same performance gain with a 100 $s worth of CPU or a faster disk. In addition all extra code reduces reliability no matter how good it is. Another option would be to switch from using libxml2 to expat for the XML parsing. Depends. libxml2 has much more functionality, especially a DOM implementation. If you are only doing SAX, expat may be an option. I doubt however that it will give you a speed gain. Sincerely, Joachim
Re: trick/tips for finding memory leaks
On 11/26/07, ed [EMAIL PROTECTED] wrote: Generally speaking, if you're using apr routines then they should handle the memory resources for you, there should be little need for allocating on the heap.
