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=""
level="all"
path="/var/logs/resin/out.log"
rollover-period="1W"
archive-format="out-%Y-%W.log.gz"
timestamp="[%m-%d %H:%M:%S.%s] {%{thread}} "
format=" ${log.level} (${log.name}) ${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
>> -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
