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

Reply via email to