Open jnbek opened 12 years ago
The backend part of Supersonic was nearly unchanged from Subsonic's, so chances that the issue is due to memory leakage are somewhat slim. But yes, you never know.
Let me ask you this: Are your Subsonic and Supersonic instances comparable? Do both run under Tomcat? Do you measure memory consumption after both systems have had enough time to warm up?
If all equal, I'd be curious to know if a Subsonic build from source exhibits similar consumption values. Would you mind trying that out?
A: Yes both instances are identical, 30,000 media files, mostly mp3 with a smattering of ogg and flac and a cpl wavs (my own music i record). B: Both are running in the same jail, on FreeBSD 8.3-STABLE with Tomcat 6.0.35. I do not run both together, it's either one or the other. C: Yes, I've allowed both systems to warm up, warm up meaning to me, Start Tomcat with each instance 'deployed', wait for CPU usage to: aa: Tank to 110% for a few minutes while the instance parses the library. bb: Finish tanking to 110%, Allowing CPU usage to level off to it's usual 0.1% cc: At this point, from htop note the tomcat process and check the RES and VIRT columns Subsonic : RES: ~180-185M VIRT: ~890M Supersonic: RES: 300-380M VIRT: ~900M The similarities in VIRT usage is not alarming, however the RES column's differences are quite significant. Opening a web browser to http://jailip:8080/subsonic results in login and movement towards the interface. When deploying Subsonic. Opening the web browser to http://jailip:8080/supersonic immediately throws the Out of Memory error. When Supersonic is deployed.
I have yet to try building Subsonic from source, I will attempt to do so this evening or possible at the latest tomorrow. (I am UTC -600) and I will report the results to you. I am not beyond the idea that the fault rests with me, I have little experience with Tomcat and Java application development, deployment, etc etc... I'm a BSD Nerd for hobby and a Perl Zealot by trade/hobby. My first experience with Tomcat/etc was Subsonic and Supersonic, my first experience with building a Maven managed app. That said, I will attempt to build stock subsonic in the same manner i built supersonic and we'll go from there.
It may help to pastebin "sudo jmap -histo 3051" for both instances, where 3051 must be replaced with the running pid. This will generate a histogram of object instances (rank, instance count, total size) and may reveal what's eating up the RAM.
I'm running FreeBSD 9.0-RELEASE and have seen similar memory and performance changes in the current code base since earlier this year. I have temporally coped by increasing memory supersonic.sh --max-memory=768
at start up, however long term I think there might have a fix ready. I was looking at the upstream branch realized it's 5 months ahead of my last merge, so I think a catch up to 4.7.beta3 will be beneficial.
I will try the jmap hopefully this evening, I was unable to get around to sshing up to the jail last night, I had a rather brutal visit with a Chiropractor and pretty much knocked me cold.... There really has to be a less painful treatment for spinal related migraines....... heh: exit(0); anyways I'll get back to y'all soon as I get the jmap output.
I must apologize, I haven't been able to get a chance to get the testing done, my grandfather in close to death, I caught a damned head cold, my lingering spinal problems have been flaring up, and had my debit card compromised on Facebook.... So needless to say, I've not had the spare cycles to spend running tests with regard to this issue, please leave open, I will get to this asap.
Sorry to hear about the illnesses. No big hurry, I'm hoping to have some extra time to back merge code so we can catch up to upstream. I'm thinking there some important bug fixes and optimizations we haven't incorporated yet.
Hope you feel better soon! On Aug 23, 2012 9:07 AM, "John D Jones III" notifications@github.com wrote:
I must apologize, I haven't been able to get a chance to get the testing done, my grandfather in close to death, I caught a damned head cold, my lingering spinal problems have been flaring up, and had my debit card compromised on Facebook.... So needless to say, I've not had the spare cycles to spend running tests with regard to this issue, please leave open, I will get to this asap.
— Reply to this email directly or view it on GitHubhttps://github.com/Mach5/supersonic/issues/64#issuecomment-7974722.
Ding dong, random stranger popping in, just learned about Subsonic last week and Supersonic today.. are there still issues with memory on FreeBSD? Like jnbek above, I'm relatively unfamiliar with Maven and Java deployments, and was about to embark on a similar quest of compiling from source on 8.3-STABLE, but ran into this
@snicker: I don't think the issue has been resolved yet. You'll have to build on your own and apply porkcharsui's workaround described above in case you run into any memory problems.
Is there a compile argument you can pass for adjusting memory settings etc?? I seem to remember something of the sort in either Wave-in-a-Box or Gisgraphy when I was playing with them..,, could that be something to consider?
Yea, I'm still here, and honestly until the other day... I had forgot all about this bug... I will follow up with some things, update my source and try again.. I changed jobs from Developer to SysAdmin (just a title change really, I still program about as much as I always have, just now I can do some hardware work too now :D)
I built Supersonic from source on FreeBSD 8.3-STABLE, and it ran fine and was easy to setup and everything, but the idle memory usage was over 300MB, where my original Subsonic 4.7 install never exceeds 180MB for memory use, Supersonic, would error out on most operations saying it was out of memory, with the memory pegged at ~380MB... The machine has plenty of memory, and with Subsonic working fine on the same machine, it makes me wonder what I did wrong? Is there a memory leak somewhere? I'm using FreeBSD's latest OpenJDK 6 and Tomcat 6. The only difference between the installations being Supersonic being build from source.