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.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 mailing list
resin-interest mailing list