I replied with the thread dump, but don't see it appearing in the list. Seems like the list server is flaky.
On Mar 18, 2010, at 14:37:25, Scott Ferguson wrote: > Rick Mann wrote: >> Slower is subjective. Unfortunately, I can't currently run the old server to >> actually measure times, but it's just slowwwww. I can see individual >> requests (images, CSS, etc) taking a long time to be fulfilled, whereas >> before, the pages would just come up fully rendered. Time to first render is >> longer, too. >> > "finer" logging might show the issue, but there's a good chance it's > related to the connection issue. >> I left the server running late last night, tried to make requests of it this >> morning, but I just got "server not responding" errors in the browser. Mind >> you, these were not timeouts, but actual connection refusals. >> > Thanks. Refusing connections is a more helpful description. > > If possible, can you get a thread dump in that situation? There are a > couple of possible scenarios: > > 1. After a while, Resin no longer has a thread listening for an > accept(). (for example, if it doesn't properly spawn a new thread.) > 2. The JVM is truly frozen. > > It is possible, by the way, that the older Linux is having trouble with > the threading. They made huge improvements in the kernel's threading > after the version you're using. >> logs show nothing with this config: >> >> >> <logger name="com.caucho.servlets" level="warning"/> >> <logger name="" level="warning"/> >> > Ok, although, the "warning" level would only show pretty serious issues. >> So, that's an interesting and scary thought. However, I'm not using Resin >> Professional, so I thought I didn't get native sockes. >> > Ok. That's one less variable. The main issue is the connection failures. > That could cause your slowness as well. For example, if only one thread > is listening for connections for some reason, the server would appear to > be very slow. > > -- Scott >> >>>> root 20511 0.0 5.1 226964 26396 pts/2 S 10:54 0:00 >>>> /usr/java/bin/java -jar /usr/local/resin/lib/resin.jar -conf >>>> /var/resin/resin.xml -log-directory /var/logs/resin -root-directory >>>> /var/resin/root -J-verbosegc console >>>> >>>> root 20517 0.0 6.8 450916 35108 pts/2 S 10:54 0:00 >>>> /usr/local/java-versions/jdk1.6.0_07/bin/java -server >>>> -Djava.awt.headless=true -Dfile.encoding=utf-8 -Dresin.server=1 >>>> -Djava.util.logging.manager=com.caucho.log.LogManagerImpl >>>> -Djava.system.class.loader=com.caucho.loader.SystemClassLoader >>>> -Djavax.management.builder.initial=com.caucho.jmx.MBeanServerBuilderImpl >>>> -Djava.awt.headless=true -Dresin.home=/usr/local/resin/ -Xss1m -Xmx256m >>>> -verbosegc -verbosegc com.caucho.server.resin.Resin --root-directory >>>> /var/resin/root -conf /var/resin/resin.xml -socketwait 34280 >>>> -log-directory /var/logs/resin -root-directory /var/resin/root console >>>> >>>> >>>> I can't find where the -Xss1m and -Xmx256m are being set. According to the >>>> admin manual, it should default to -Xss2m. >>>> >>>> >>> You can change that in the resin.xml with a <jvm-arg>-Xss1m</jvm-arg>. >>> >> >> I used to have exactly those values specified in resin.xml, and thought >> perhaps that was part of the problem, so I commented them out (to let the >> JVM and resin pick defaults). I was still seeing those in the command, >> though, and didn't know where they were coming from. That was something I >> had not been specifying in my 3.0.23 installation, and so I thought they >> were causing more problems than they were solving. >> >> >> >> >> >> _______________________________________________ >> resin-interest mailing list >> resin-interest@caucho.com >> http://maillist.caucho.com/mailman/listinfo/resin-interest >> >> > > > > _______________________________________________ > resin-interest mailing list > resin-interest@caucho.com > http://maillist.caucho.com/mailman/listinfo/resin-interest _______________________________________________ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
