Thursday, February 02, 2006

Performance, Architectural Limits and RAM

Just for future reference, I dug this up from the Microsoft site when I was trying to figure out why my jvm was imploding. You can definitely hit some of these limits earlier than you would think. The tricky part is that your box can be humming along quite nicely while one trouble-making app runs into one of these barriers.

On machines where you have 2GB of memory or more, you shouldn't set your maximum heap size larger than 1430 MBytes.

On any computer system, as load (number of users, amount of work being done) increases, performance (how long it takes to do each task) will decrease, but in a non linear fashion. Any increase in load (demand) beyond a certain point will result in a dramatic decrease in performance. This means that some resource is in critically short supply and has become a bottleneck.

At some point, the resource in critical short supply can not be increased. This means an architectural limit has been reached. Some commonly reported architectural limits in Windows include:

  1. 2 GB of shared virtual address space for the system
  2. 2 GB of private virtual address space per process
  3. 660 MB System PTE storage
  4. 470 MB paged pool storage
  5. 256 MB nonpaged pool storage

One sure fire way to run into this issue is to stuff lots of nested components into the session scope. Add a few cross joins to populate them with lots of meaningless data and you'll have a meltdown almost as fast as building infinite loops.

No comments:

Post a Comment