Sorry in advance for the newbie question, but I have a dedicated virtual server I'm working on that has 512MB of RAM memory. I've recently changed the memory_limit from the default of 128M to 256M. Is there any reason why I wouldn't want to bump this all the way up to the full 512M that's available?
Setting memory_limit in php.ini – can I use all of the available system memory
memoryphp.ini
Related Solutions
Based on the snapshot here, the memory utilization seems fine and an upgrade wouldn't be necessary (and probably wouldn't help).
Free & top both state that there is just ~50 MB or so free, but when accounting for buffers, that number is significantly higher. Linux is going to use any unallocated/unused physical RAM as cache & buffer space. If your applications need more memory, brk & sbrk will yank it from cache. There are performance implications as that happens more frequently, but that's probably not a concern here at all.
Now, it's very possible that you're indeed spiking on occasion during times of high traffic or maintenance script runs. Do you have any cron jobs scheduled that execute large queries as part of a cleanup process or anything? Is there anything that might swallow up RAM temporarily and then release it? Account freeze batch jobs or anything?
All that said, can you describe your problem a bit more? If you're not able to ping the system, I highly, highly doubt it's a memory problem at all. Does your server just go away for a while and then come back? Check your web server logs during that period, is there a period of inactivity for everyone, or just you? If your machine is just falling off of the planet for a period of time, I'd vote that it's something network related.
What about dmesg output? Net device errors?
You won't be able to use AWE with Windows 2003 Standard. You need Enterprise, see Large memory support is available in Windows Server 2003 and in Windows 2000:
PAE is the added ability of the IA32 processor to address more than 4 GB of physical memory. The following operating systems can use PAE to take advantage of physical memory beyond 4 GB:
* Microsoft Windows 2000 Advanced Server * Microsoft Windows 2000 Datacenter Server * Microsoft Windows Server 2003, Enterprise Edition * Microsoft Windows Server 2003, Datacenter EditionTo enable PAE, use the /PAE switch in the Boot.ini file.
The working set you see is 7MB, not 7GB. That is a normal working set for a process, since working set don't measure the amount of memory allocated to a process, but only the working set which is always much much smaller:
Shows the current number of bytes in the working set of this process. The working set is the set of memory pages touched recently by the threads in the process. If free memory in the computer is above a certain threshold, pages are left in the working set of a process even if they are not in use. When free memory falls below a certain threshold, pages are trimmed from working sets. If they are needed, they are then soft-faulted back into the working set before they leave main memory.
You need to look at Process\Virtual Bytes instead:
Shows the current size, in bytes, of the virtual address space that the process is using. Use of virtual address space does not necessarily imply corresponding use of either disk or main memory pages. Virtual space is finite, and by using too much, the process can limit its ability to load libraries.
The SQL Server memory is 3GB, which is all it can allocate on Windows Standard with /3GB switch.
So you'll need to purchase a Enterprise Windows license, or simply move to an 64 bit OS and 64 bit SQL deployment (which is really the only sane option).
Best Answer
Yes - the first is that's 512MB per PHP process. Do your processes really need that much?
Some reasons I can come up with that haven't already been covered:
Setting a limit that high will only encourage clumsy programming (I can't imagine PHP would be the best language to pick if you need half a gig of ram in one shot)
Potentially denial of service attacks (e.g. if you do upload processing in memory, and the user knows that, they'll just upload some really large files and knock your server offline - rather than you server hitting 32/64/128M, it'll hit all the way to 512M). This is assuming you don't have other upload limits that aren't hit first.
You have a virtual server. If it's OpenVZ/Virtuozzo and you can't burst to more than 512M, then your processes will start to get killed - fast. Apache will probably be knocked offline, especially when using dso. This will put everything down until it's restarted.
You won't know if this'll cause a major problem until one starts to surface. Unlike more complex memory management, PHP makes no attempt to allocate this much memory at the start. It simply says it'll keep trying until you try to use more than this, then give up. For all you know, you might not be able to get anywhere near 512MB in the first place - so you can't assume just because you've restarted Apache and everything still works, that you are fine.
Suppose you do have an application that requires 512M of memory. Why make that limit for all other processes too? You risk creating the problems above for all of them. With a standard installation, the script that requires it (e.g. a large cron job) can just do
ini_set('memory_limit','512M');in PHP and raise it's own limit. That leaves all other processes 'safe'Here are some more lower-level reasons:
Your entire virtual server is allocated 512M. That has to be divided into processes just to keep the server running, such as (at a minimum)
It's not possible to squeeze all of these other processes and a 512M PHP process, within your total 512M memory.
On top of this, the kernel will optimise unused ram into a cache - so carelessly having a high limit risks a performance penalty for no real reason.
Confirm if you have swap (verify using
toporfree -m). If you do, your virtual server will slow dramatically when you hit the limit. If you don't have swap, your processes will be killed by the hypervisor. Either way, you're going to see a performance hit.So, in summary, I wouldn't advise raising a global limit for something like this.