Thanks for getting back to me, Scott! Responses below

On Mar 18, 2010, at 12:37:21, Scott Ferguson wrote:

> Rick Mann wrote:
>> My 4.0.5 install is really very slow. It just won't stay running (although 
>> ps shows many resin threads), and it's much, much slower than 3.0.23 was. 
>> I'm actually running fewer webapps currently, and my server is always idle.
> How are you measuring the "slower"? (ab? latency? startup? some 
> particular page size?) If the server is idle, how is it slow?

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.

> Also, I'm not sure I understand you mean by "not-running" if there are 
> Resin threads. Do the two JVMs exist? What do the logs show?

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.

logs show nothing with this config:

    <log-handler name=""
            timestamp="[%m-%d %H:%M:%S.%s] {%{thread}} "
            format=" ${log.level} (${}) ${log.message}"/>
        <logger name="com.caucho.servlets"                  level="warning"/>
        <logger name=""                                     level="warning"/>

I'm not sure how to verify that the JVMs exist, other than the ps command 
outputs many lines for java (as described before). It's not that the server 
died, it just stopped listening.

>> Configuration is slightly different than it used to be, a necessity of 
>> updating the config file(s), but I don't think it's radically different from 
>> what I had.
>> ps -axwwu | grep resin on redhat 7.2 (I know, it's old) gives me many lines 
>> like this:
> Hmm. If it's showing separate ps lines for each thread, that's very old. 
> Some of those very old linux versions only partially implemented some of 
> the system calls we use, like epoll(). (So the configure script would 
> discover epoll(), but it didn't actually work as advertised.)

So, that's an interesting and scary thought. However, I'm not using Resin 
Professional, so I thought I didn't get native sockes.

>> 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 
>> -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

Reply via email to