RE: heap size problems (speed) [2]
> From: Cristian S [mailto:[EMAIL PROTECTED] > Frankly I have no ideea what's the point of loading almost > 400M of data in memory in a HashMap. > Maybe this very approach has a design flaw when it comes to JAVA. If it's expensive to generate / load that data and the app has tight response time restrictions, and if there's enough RAM to keep the data in main memory without paging, and if the heap is large enough to allow other processing to take place, and if the map is set up so that there are few collisions, then the map is a very sensible approach. That's a lot of ifs. I'd try the following: - Check for paging traffic on your server. Are other apps causing Tomcat to be paged out, leading to expensive disk I/O when the map is accessed? - Follow Chuck's suggestion to check for garbage collection activity. If possible, try increasing the Java heap size (and check for paging activity on the server). - Talk to your dev team to find out how well or badly the map is keyed. A HashMap with a lot of entries can be slow if the hash for the key is poor. I'd expect to see high CPU usage *or* high paging activity if this was the case, as the server will either spend a lot of its time hashing or have to load a lot of pages from backing store to examine them for hash keys. Neither is pleasant. Java HashMaps aren't inherently slow; something's poorly configured. Those are a few guesses, no more than that. I also suspect it's *not* your CPU cache size. Yes, going to RAM is slower than loading from a processor cache line, but it's still a *lot* faster than retrieving a row from the database. I'd be looking elsewhere. Intel have spent a lot of money making people think that the CPU is the only contributor to overall system speed; RAM and disk I/O speeds play a much larger part these days. - Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
Agreed for memory profiler I would check out http://www.khelekore.org/jmp/ If this solution is workable you may want to set environment variable JAVA_OPTS to include -verbose:gc Martin- - Original Message - From: "Caldarale, Charles R" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, November 28, 2005 6:18 PM Subject: RE: heap size problems (speed) [2] > From: Cristian S [mailto:[EMAIL PROTECTED] > Subject: Re: heap size problems (speed) [2] > > Frankly I have no ideea what's the point of loading almost > 400M of data in memory in a HashMap. "If it's worth doing, it's worth doing to excess." Or maybe not. Try turning on -verbose:gc and see if you're going through a lot of garbage collections. If your max heap is 512mb and you're using 400mb of it for the cache, there may not be much left for request processing. Should also try a memory profiler to see just how full the heap really is. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: heap size problems (speed) [2]
> From: Cristian S [mailto:[EMAIL PROTECTED] > Subject: Re: heap size problems (speed) [2] > > Frankly I have no ideea what's the point of loading almost > 400M of data in memory in a HashMap. "If it's worth doing, it's worth doing to excess." Or maybe not. Try turning on -verbose:gc and see if you're going through a lot of garbage collections. If your max heap is 512mb and you're using 400mb of it for the cache, there may not be much left for request processing. Should also try a memory profiler to see just how full the heap really is. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: heap size problems (speed) [2]
1024 K is still relatively small compare to a heap size of 512M. The fact is that Duron is really the low-end of AMD processor family. It shouldn't be used for any serious computing purpose. I'd like to suggest doing the test at least on an Athlon. Hardware is really cheap nowadays. ND -Original Message- From: Cristian [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:27 PM To: Tomcat Users List Subject: Re: heap size problems (speed) [2] - Original Message - From: "Duan, Nick" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, November 28, 2005 7:30 PM Subject: RE: heap size problems (speed) [2] > Were you using the right JVM? There were two JDK download for LINUX on > Sun's web site. I have downloaded : J2SE(TM) Development Kit 5.0 Update 5 Linux self extracting file (although I think I should have get the rpm). I've extrated it in a separate directory and set JAVA_HOME in tomcat to point to that dir. Does it make any difference other than the fact that this way it is not rpm compliant? > The main problem may be your AMD Duron processor which has a very small > cache size (I believe it's about 512K). Once the processor cache > reaches its limit, increasing the JVM heap size won't be very effective. This is even worse for my AMD Duron cache size : 64 KB but on the other machine I have : cache size : 1024 KB and still get the same results. Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
- Original Message - From: "Wade Chandler" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, November 28, 2005 11:27 PM Subject: Re: heap size problems (speed) [2] I don't know really. I've not seen issues with HashMap in a Linux vs. Windows scenario (might check JRE/JDK bug reports). Since your swap isn't being hit all the time I wouldn't say it would be that. I don't know really where to direct you without knowing more, because the general issues don't seem to be the cause. Does the application perform badly with only a few hits to the site? Does the application get under heavy load then stop working? Unfortunatelly this test application performs badly from the first hit. Frankly I have no ideea what's the point of loading almost 400M of data in memory in a HashMap. Maybe this very approach has a design flaw when it comes to JAVA. Luckly this is only a test and I'm being asked why it does not work on Linux and mostly if I can take it out from this "won't budge" state :). Anyway, I will take a closer look at the problem of JRE/JDK possible bugs and perhaps at some kernel settings that might cause this. Or maybe I'm just missing/mistaking something and I do not realize for the moment. Wade Thanks a lot, Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
--- Cristian <[EMAIL PROTECTED]> wrote: > > I don't think your CPU L caches are going to > influence > > the issues you are seeing...not noticeably..not > with > > todays hardware. Cristian is resizing the java > heap > > to allow it to get larger than it was able before > > (default or the Tomcat default setting). In this > case > > heap being the amount of memory the java process > is > > going to be able to use for the process aside from > the > > static space which can not be controlled by the > heap > > setting being used. > > > > How much memory does your computer physically have > > Cristian? Are you also using -Xms512m? I'll wait > to > > here about your memory first before making other > > comments on that. > > > 1G of RAM and I do not set -Xms512m > swap space is hit ocasionaly but not all the time. > > > The next thing I'm going to ask deals with another > > issue we had on the list. Do you also write to > the > > HashMap from your application? Are you reading > and > > writing to this cache or your application loads > this > > cached data at start up and it is merely read from > > that point on? If you are writing to this data > you > > need to be sure to synchronize the HashMap because > if > > you don't you can get into some serious problems > with > > concurrency issues and HashMap resizing > (synchronize > > reads and writes). If you load all of the data up > > then only read from the application then > synchronizing > > the reads to the hash map won't matter (unless you > > allow reading while the loading is occuring). > > The application only caches data at startup and > after that it performs > only read operations regarding this cache. > > > The next question would be: Even if only reading > and > > you are are currently synchronizing the calls to > this > > "cached" data are the operations long? If the > > operations to a synchronized resource are very > long > > then other threads (requests in this case) will be > > delayed while trying to access the HashMap. > > I'm told that the accesses are not "long ones" ... > The designer of this > test > just accesses the HashMap. If it exists, OK they > return the value. > If not they return the name of the requested key. > > Please don't blame my lack of knowledge in this > matter, this being only > what they've told me. > I am far away (hundreds of pages of java docs) from > understanding the > functionality. > I'm only providing support on linux for tomcat > (installation with APR > etc). > They wanted to test this scenario on linux because > on windows they claim > it worked. > > However I can understand advises and put them into > practice if needed. > Also, as I said before, I am able to read some docs > that would > eventually get me to the point of solving and > understanding the problem. > > > Wade > > Thanks, > Cristian > I don't know really. I've not seen issues with HashMap in a Linux vs. Windows scenario (might check JRE/JDK bug reports). Since your swap isn't being hit all the time I wouldn't say it would be that. I don't know really where to direct you without knowing more, because the general issues don't seem to be the cause. Does the application perform badly with only a few hits to the site? Does the application get under heavy load then stop working? Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
> I don't think your CPU L caches are going to influence > the issues you are seeing...not noticeably..not with > todays hardware. Cristian is resizing the java heap > to allow it to get larger than it was able before > (default or the Tomcat default setting). In this case > heap being the amount of memory the java process is > going to be able to use for the process aside from the > static space which can not be controlled by the heap > setting being used. > > How much memory does your computer physically have > Cristian? Are you also using -Xms512m? I'll wait to > here about your memory first before making other > comments on that. 1G of RAM and I do not set -Xms512m swap space is hit ocasionaly but not all the time. > The next thing I'm going to ask deals with another > issue we had on the list. Do you also write to the > HashMap from your application? Are you reading and > writing to this cache or your application loads this > cached data at start up and it is merely read from > that point on? If you are writing to this data you > need to be sure to synchronize the HashMap because if > you don't you can get into some serious problems with > concurrency issues and HashMap resizing (synchronize > reads and writes). If you load all of the data up > then only read from the application then synchronizing > the reads to the hash map won't matter (unless you > allow reading while the loading is occuring). The application only caches data at startup and after that it performs only read operations regarding this cache. > The next question would be: Even if only reading and > you are are currently synchronizing the calls to this > "cached" data are the operations long? If the > operations to a synchronized resource are very long > then other threads (requests in this case) will be > delayed while trying to access the HashMap. I'm told that the accesses are not "long ones" ... The designer of this test just accesses the HashMap. If it exists, OK they return the value. If not they return the name of the requested key. Please don't blame my lack of knowledge in this matter, this being only what they've told me. I am far away (hundreds of pages of java docs) from understanding the functionality. I'm only providing support on linux for tomcat (installation with APR etc). They wanted to test this scenario on linux because on windows they claim it worked. However I can understand advises and put them into practice if needed. Also, as I said before, I am able to read some docs that would eventually get me to the point of solving and understanding the problem. > Wade Thanks, Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
--- Cristian <[EMAIL PROTECTED]> wrote: > > - Original Message - > From: "Duan, Nick" <[EMAIL PROTECTED]> > To: "Tomcat Users List" > Sent: Monday, November 28, 2005 7:30 PM > Subject: RE: heap size problems (speed) [2] > > > > Were you using the right JVM? There were two JDK > download for LINUX > on > > Sun's web site. > > I have downloaded : J2SE(TM) Development Kit 5.0 > Update 5 > Linux self extracting file (although I think I > should have get the rpm). > > I've extrated it in a separate directory and set > JAVA_HOME in tomcat to > point to that dir. > > Does it make any difference other than the fact that > this way it is not > rpm compliant? > > > The main problem may be your AMD Duron processor > which has a very > small > > cache size (I believe it's about 512K). Once the > processor cache > > reaches its limit, increasing the JVM heap size > won't be very > effective. > > This is even worse for my AMD Duron > cache size : 64 KB > > but on the other machine I have : > cache size : 1024 KB > and still get the same results. > > Cristian > > > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > I don't think your CPU L caches are going to influence the issues you are seeing...not noticeably..not with todays hardware. Cristian is resizing the java heap to allow it to get larger than it was able before (default or the Tomcat default setting). In this case heap being the amount of memory the java process is going to be able to use for the process aside from the static space which can not be controlled by the heap setting being used. How much memory does your computer physically have Cristian? Are you also using -Xms512m? I'll wait to here about your memory first before making other comments on that. The next thing I'm going to ask deals with another issue we had on the list. Do you also write to the HashMap from your application? Are you reading and writing to this cache or your application loads this cached data at start up and it is merely read from that point on? If you are writing to this data you need to be sure to synchronize the HashMap because if you don't you can get into some serious problems with concurrency issues and HashMap resizing (synchronize reads and writes). If you load all of the data up then only read from the application then synchronizing the reads to the hash map won't matter (unless you allow reading while the loading is occuring). The next question would be: Even if only reading and you are are currently synchronizing the calls to this "cached" data are the operations long? If the operations to a synchronized resource are very long then other threads (requests in this case) will be delayed while trying to access the HashMap. Wade - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: heap size problems (speed) [2]
- Original Message - From: "Duan, Nick" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Monday, November 28, 2005 7:30 PM Subject: RE: heap size problems (speed) [2] > Were you using the right JVM? There were two JDK download for LINUX on > Sun's web site. I have downloaded : J2SE(TM) Development Kit 5.0 Update 5 Linux self extracting file (although I think I should have get the rpm). I've extrated it in a separate directory and set JAVA_HOME in tomcat to point to that dir. Does it make any difference other than the fact that this way it is not rpm compliant? > The main problem may be your AMD Duron processor which has a very small > cache size (I believe it's about 512K). Once the processor cache > reaches its limit, increasing the JVM heap size won't be very effective. This is even worse for my AMD Duron cache size : 64 KB but on the other machine I have : cache size : 1024 KB and still get the same results. Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: heap size problems (speed) [2]
Were you using the right JVM? There were two JDK download for LINUX on Sun's web site. The main problem may be your AMD Duron processor which has a very small cache size (I believe it's about 512K). Once the processor cache reaches its limit, increasing the JVM heap size won't be very effective. ND -Original Message- From: Cristian [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 6:19 AM To: Tomcat Users List Subject: heap size problems (speed) [2] Although it may seem obvious what is the problem, I forgot to ask the question so I'm doing it now: What could be the problem in the below described situation ? I would appreciate if you point some docs that I should read to solve the issue. Thanks again, Cristian Original message follows: Hello, I have an instance of tomcat with APR support which is set to allocate more heap memory than default (by passing -Xmx512M option to JAVA_OPTS in catalina.sh). Under this instance runs a test application which gets data from a database and makes a cache with the fetched data (around 350M). When the app is accessed it is supposed to return data from the cache (which is in a form of a hashmap) faster than getting it from the database. After the caching is done the application responds extremely slow and above this many images aren't loaded or they are loaded partially in the browser (I haven't checked to see if the images are the only ones that are not loaded). The system: = Kernel: Linux server2 2.6.14-1.1637_FC4 #1 Wed Nov 9 18:19:37 EST 2005 i686 athlon i386 GNU/Linux = Processor: AMD Duron 1000MHz = Tomcat: 5.5.12 with APR 1.2.2 (compiled apart from apr-0.9.6-3.1 which is in the distrib) = RAM: 1G The system has all updates. I am not the one who wants the test so don't blame me for any stupidity that you might found in this scenario :). I get the same results on a different machine which is much faster and has twice as much memory than this one from the test. Thanks, Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
heap size problems (speed) [2]
Although it may seem obvious what is the problem, I forgot to ask the question so I'm doing it now: What could be the problem in the below described situation ? I would appreciate if you point some docs that I should read to solve the issue. Thanks again, Cristian Original message follows: Hello, I have an instance of tomcat with APR support which is set to allocate more heap memory than default (by passing -Xmx512M option to JAVA_OPTS in catalina.sh). Under this instance runs a test application which gets data from a database and makes a cache with the fetched data (around 350M). When the app is accessed it is supposed to return data from the cache (which is in a form of a hashmap) faster than getting it from the database. After the caching is done the application responds extremely slow and above this many images aren't loaded or they are loaded partially in the browser (I haven't checked to see if the images are the only ones that are not loaded). The system: = Kernel: Linux server2 2.6.14-1.1637_FC4 #1 Wed Nov 9 18:19:37 EST 2005 i686 athlon i386 GNU/Linux = Processor: AMD Duron 1000MHz = Tomcat: 5.5.12 with APR 1.2.2 (compiled apart from apr-0.9.6-3.1 which is in the distrib) = RAM: 1G The system has all updates. I am not the one who wants the test so don't blame me for any stupidity that you might found in this scenario :). I get the same results on a different machine which is much faster and has twice as much memory than this one from the test. Thanks, Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
heap size problems (speed)
Hello, I have an instance of tomcat with APR support which is set to allocate more heap memory than default (by passing -Xmx512M option to JAVA_OPTS in catalina.sh). Under this instance runs a test application which gets data from a database and makes a cache with the fetched data (around 350M). When the app is accessed it is supposed to return data from the cache (which is in a form of a hashmap) faster than getting it from the database. After the caching is done the application responds extremely slow and above this many images aren't loaded or they are loaded partially in the browser (I haven't checked to see if the images are the only ones that are not loaded). The system: = Kernel: Linux server2 2.6.14-1.1637_FC4 #1 Wed Nov 9 18:19:37 EST 2005 i686 athlon i386 GNU/Linux = Processor: AMD Duron 1000MHz = Tomcat: 5.5.12 with APR 1.2.2 (compiled apart from apr-0.9.6-3.1 which is in the distrib) = RAM: 1G The system has all updates. I am not the one who wants the test so don't blame me for any stupidity that you might found in this scenario :). I get the same results on a different machine which is much faster and has twice as much memory than this one from the test. Thanks, Cristian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
