Re: Question about 'top' values on memory usage
In the last episode (Oct 14), Artem Kuchin said: Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? Determining the amount of shared vs unshared memory for each process is not totally trivial. All I can suggest is using procfs and reading /proc/PID/map eg: turion% dd if=/proc/curproc/map bs=256k 0x40 0x402000 2 0 0xff002e4710e0 r-x 1 0 0x0 COW NC vnode /bin/dd 0x502000 0x503000 1 0 0xff001c41cd20 rw- 2 0 0x2180 NCOW NNC default - 0x503000 0x505000 2 0 0xff001c41cd20 rwx 2 0 0x2180 NCOW NNC default - and so on The columns are: start address, end address, resident pages, private resident pages, vm_object_t address, protection, reference count, shadow count, flags, cow, copy-needed, type, path See vm/vm_object.h for flags This will let you indentify shared vs private space as well as whether it's file or swap backed. -- Peter Jeremy pgpTgKJQKBT1Q.pgp Description: PGP signature
Re: Question about 'top' values on memory usage, now threads
On 2007-Oct-15 12:43:39 -0400, William LeFebvre [EMAIL PROTECTED] wrote: Whether there is actual swapping going on or not, processes will still need swap space. There needs to be a backing store for every page that's in physical memory. This isn't true for FreeBSD. You can even totally disable paging/swapping with the config option NO_SWAPPING if you want. FreeBSD allocates swap space on an as needed basis, rather than pre-allocating swap. The advantage is that a process can request virtually unlimited amounts of memory via sbrk(2), mmap(2) or malloc(3). The downside is that a process may be killed without notice when it writes to some previously allocated but unused part of its address space. See the archives for the full bikeshed. -- Peter Jeremy pgpC1oPyT0BbR.pgp Description: PGP signature
Re: Question about 'top' values on memory usage
Artem Kuchin wrote: Hello! Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? Another question is that is httpd uses threads (as provided by FreeBSD) starting a new thread will or will not copy executable copy and data? Basically, will a new thread eat another 4300K or just a little bit for its data? SIZE is the total amount of virtual memory that a process has allocated. This includes text, data, and stack. It also includes all the stuff that's shared with other processes (mostly through the use of shared libraries). RES is the amount of physical memory in use by the process and will only include that part of a process's virtual memory space which is currently allocated in physical memory. Unfortunately, freebsd does not appear to track the amount of shared virtual memory for each process. It could be obtained by walking through all the pages in a process's vm map, but that would really slow top down. I don't know of any freebsd utility that would give that information for an individual process. But hey, if it's out there somewhere where it is easy to grab, I would be very happy to add it to top. All this i need to calculate maximum possible number of https i can run on a box with certain amount of memory and select proper MPM for Apache. Somehow, i could not find any practical info on this regarding FreeBSD. That's because the answer isn't as straightforward as you want it to be. There are actually two things you need to worry about: swap space and physical memory. The amount of swap space will place a hard upper bound on the number of httpd processes you can run before sbrk (and thus malloc) start failing. In order to determine that amount you are going to have to see how much extra swap is gobbled up by each new process. But in actuality that swap is only taken when needed, and if a data page remains untouched by the process then it won't need to allocate swap (backing store) for that page. At least that's my limited understanding of how the freebsd VM model works. But I would argue that long before you hit that hard upper limit you will hit a much more serious practical limit in just how much physical memory is adequate for the environment. And that doesn't really limit the number of processes, rather it limits how many of them can be active at a given time. You're not just going to be able to sit down and plug numbers in to a formula and say voila!. You will have to observe how httpd performs in your particular environment to see how many page faults per second it generates and decide for yourself the point at which X pf/s is too much. Personally, based on my experience, I would be more concerned with the amount of available cpu cycles than memory. In my experience, once you run out of idle time on a web server you have exceeded its capacity to serve pages. In that situation it doesn't matter how many httpd processes there are, the system is still not able to keep up with demand. And that will probably happen before the system starts thrashing from limited memory. Bill LeFebvre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage
William LeFebvre wrote: Artem Kuchin wrote: Hello! Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? Another question is that is httpd uses threads (as provided by FreeBSD) starting a new thread will or will not copy executable copy and data? Basically, will a new thread eat another 4300K or just a little bit for its data? SIZE is the total amount of virtual memory that a process has allocated. This includes text, data, and stack. It also includes all the stuff that's shared with other processes (mostly through the use of shared libraries). RES is the amount of physical memory in use by the process and will only include that part of a process's virtual memory space which is currently allocated in physical memory. Unfortunately, freebsd does not appear to track the amount of shared virtual memory for each process. It could be obtained by walking through all the pages in a process's vm map, but that would really slow top down. I don't know of any freebsd utility that would give that information for an individual process. But hey, if it's out there somewhere where it is easy to grab, I would be very happy to add it to top. My knowledge of VM system of FReebSD is so low, that even though i can write in C i don't know where to start here. I haven't found anything ready for this. make search in port on 'memory' and 'ram' does not return much. All this i need to calculate maximum possible number of https i can run on a box with certain amount of memory and select proper MPM for Apache. Somehow, i could not find any practical info on this regarding FreeBSD. limits how many of them can be active at a given time. You're not just going to be able to sit down and plug numbers in to a formula and say voila!. You will have to observe how httpd performs in your particular environment to see how many page faults per second it generates and decide for yourself the point at which X pf/s is too much. Of course, but i need to start with something instead of just pure guess out of the blue. Personally, based on my experience, I would be more concerned with the amount of available cpu cycles than memory. CPU is more than just enough in my case. There will a a lot https sitting there but load, i am sure, will be low. Swapping is simply unacceptable, so i am counting only real physical ram. However, noone mentioned anything about threads. DO they give any memory advantage on freebsd? -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage, now threads
Artem Kuchin wrote: CPU is more than just enough in my case. There will a a lot https sitting there but load, i am sure, will be low. If the load is low then you may not need very many processes. Swapping is simply unacceptable, so i am counting only real physical ram. Whether there is actual swapping going on or not, processes will still need swap space. There needs to be a backing store for every page that's in physical memory. For text pages and untouched data pages, the backing store is the executable file itself. For modified data pages there needs to be some place on disk to put a page when the virtual memory system decides it needs more physical pages. This isn't really swapping: its reclaiming infrequently used physical pages when there is something else with a more immediate need, usually called a page out. When a modified data page is paged out it has to be written somewhere. That somewhere is the swap area. You can say swapping is unacceptable and that's fine. But most systems will have page outs: its just a fact of life with virtual memory systems. You can keep adding physical memory to minimize the number of page outs, and that sounds like what you want to do. And its even possible to have sufficient physical memory to ensure all processes remain memory resident. But without knowing the amount of shared virtual memory there is no easy way to determine the amount of physical memory you will need. However, noone mentioned anything about threads. DO they give any memory advantage on freebsd? Yes, threading within httpd should provide a big advantage. The top output snippet you first posted indicates that you are not using threading yet (THR column is 1). Multiple threads in the same process will share the same text and data pages, but will have their own stacks. There may be some data memory overhead in the pthreads library (and within the program itself) to track all the threads, but I believe it will be small compared to the extra memory that additional processes would use. Of course there will be additional stack space required. Finding this overhead is actually easy. Just compare a process's SIZE when running with one thread and again when running multiple threads. Bill LeFebvre ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage, now threads
William LeFebvre wrote: Artem Kuchin wrote: CPU is more than just enough in my case. There will a a lot https sitting there but load, i am sure, will be low. If the load is low then you may not need very many processes. They belong to different sites ;) so they need to be run constantly and for security reasons each site has its own http. Swapping is simply unacceptable, so i am counting only real physical ram. Whether there is actual swapping going on or not, processes will still [SNIP] However, noone mentioned anything about threads. DO they give any memory advantage on freebsd? Yes, threading within httpd should provide a big advantage. The top [SNIP] Thank you very much for the answers. You were very helpful! -- Regards, Artem ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage
* William LeFebvre [EMAIL PROTECTED] [071015 06:49] wrote: Unfortunately, freebsd does not appear to track the amount of shared virtual memory for each process. It could be obtained by walking through all the pages in a process's vm map, but that would really slow top down. I don't know of any freebsd utility that would give that information for an individual process. But hey, if it's out there somewhere where it is easy to grab, I would be very happy to add it to top. Or this could be properly accounted for when the map is updated? Personally, based on my experience, I would be more concerned with the amount of available cpu cycles than memory. In my experience, once you run out of idle time on a web server you have exceeded its capacity to serve pages. In that situation it doesn't matter how many httpd processes there are, the system is still not able to keep up with demand. And that will probably happen before the system starts thrashing from limited memory. Bill, I would have to differ with you based on personal experience, I've almost never run out of cpu on a webserver, typically it's the RAM that gets blown out. Once the server starts to page, you typically wind up with a cascade failure and the box just goes ... belly up. I would worry about ram. Typically the best way to scale a box is to load it and keep running more httpds until something happens or you reach enough httpd to service your load, at that point if something happens (ie the box tanks) you add more ram. -- - Alfred Perlstein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage
On Mon, Oct 15, 2007 at 03:08:36PM -0700, Alfred Perlstein wrote: * William LeFebvre [EMAIL PROTECTED] [071015 06:49] wrote: Unfortunately, freebsd does not appear to track the amount of shared virtual memory for each process. It could be obtained by walking through all the pages in a process's vm map, but that would really slow top down. I don't know of any freebsd utility that would give that information for an individual process. But hey, if it's out there somewhere where it is easy to grab, I would be very happy to add it to top. Or this could be properly accounted for when the map is updated? Personally, based on my experience, I would be more concerned with the amount of available cpu cycles than memory. In my experience, once you run out of idle time on a web server you have exceeded its capacity to serve pages. In that situation it doesn't matter how many httpd processes there are, the system is still not able to keep up with demand. And that will probably happen before the system starts thrashing from limited memory. Bill, I would have to differ with you based on personal experience, I've almost never run out of cpu on a webserver, typically it's the RAM that gets blown out. Once the server starts to page, you typically wind up with a cascade failure and the box just goes ... belly up. IME, it really depends mostly what kind of content you're serving; I've seen either one, or disk, be the problem. Serving mostly static pages? Don't worry about CPU, it'll be the RAM. Naive database search, not caching the results? You may get killed on disk I/O. If you're serving some kind of computationally expensive content via a CGI and the site gets hit, then it'll run out of CPU. All in all I would guess the latter's much rarer, assuming you're using a well configured webserver built with an appropriate client-connection service model. OTOH, if you can guess the process limits correctly, you can usually set them with a safety margin such that the machine won't hit the number of processes to force it into paging; it'll be unresponsive to clients above its limit, but continue to respond adequately to the clients which succeed in connecting. All IMHO. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about 'top' values on memory usage
In the last episode (Oct 14), Artem Kuchin said: Maybe someone with deeper knowledge of the internals of FreeBSD can clean up something for me (any for many others)^ Here are lines from my top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 9258 hordelo_ru1 40 40992K 4260K accept 0 0:00 0.00% httpd 9257 hordelo_ru1 440 40992K 4296K select 1 0:00 0.00% httpd 9259 hordelo_ru1 40 40992K 4292K select 1 0:00 0.00% httpd As you see, 'size' is the same for all processes, while RES varies. As i understand, the real memory taken by a process is RES and SIZE include a bunch of shares .so libs, so, if more httpd's started each will take only about 4300K more, so, 100 https will take 43K to run, right? The memory used by a process is SIZE. RES is the amount of that memory that's in memory. The rest would either be still on disk (in the form of executable or mmaped pages that haven't been accessed), in swap, or prezeroed pages that haven't been accessed yet (large blocks of malloc()'ed memory for example). Processes forked from the same parent can share the same pages until one process writes to one (a copy is then made so the other processes still see the right data). Chances are that those three httpd processes are sharing 99% of their pages. I don't know of any easy way of determing exactly how much non-shared memory a particular process has. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
