JBoss: Windows vs Linux and a Solaris boot issue
ryanlbowman at gmail.com
Mon Mar 6 13:31:52 MST 2006
On 3/6/06, Bryan Sant <bryan.sant at gmail.com> wrote:
> Are you using stateless-session-beans or stateful-session-beans?
> How are you communicating to your database? Is it running on the same
> Linux machine? What database are you using?
We run MS SqlServer 2000 running on Server 2003, jboss connects to the
db with the jtds driver 1.0.3, or 1.2 depending on which problems we
want to fight with that day (again, another story).
> What is the output of "java -version" on both Windows and Linux?
Java 1.5 on both servers
> What is the output of "ps -fe | grep java" on Linux when the app is
> running? I'm looking for the command-line args... Do the same on
> Windows... Oh wait! :-)
/usr/local/jdk1.5.0_05/bin/java -server -Xms4000m -Xmx4000m
org.jboss.Main -c rmbm -b 10.0.0.242
> What version of JBoss are you running?
> > Dual Intel Xeons, actually.
> Xeon is ambiguous to me. I haven't followed Intel closely ever since
> the Itanium nightmare. I've lost all faith in their server-class
> lines. Old Xeons are 32-bit with 33-bit memory allocation. Using a
> trick similar to old DOS XMS you can use up to 16GB of RAM. New Xeon
> processors are 64-bit (x86-64 instruction set?) and can allocate
> seemingly endless amounts of RAM with a flat memory model. Is this
> correct? Can someone correct me if I'm wrong? Is this a 64-bit chip?
That's what we understand. We're using the newer 64bit ones (we think).
> How much RAM is in the machine and how much RAM is the jboss process
> using? What is your -Xmx setting for the JVM on Linux?
6 GB total, -Xmx 4000m on the linux box, since the windows box is
32bit the jvm can only handle 1408m, and it has only 2GB of RAM
> > > What is the output of these commands (run as root):
> > > uname -r
> > 2.6.13-15-smp
> > > sysctl net.ipv4.tcp_tw_recycle
> > 0
> > > sysctl net.ipv4.tcp_keepalive_intvl
> > 75
> > > sysctl net.ipv4.tcp_fin_timeout
> > 60
> These settings are the defaults, and are fine if you're not rotating a
> lot of TCP connections. If you're using HTTP w/o pipelining or
> stateless-session-beans, then you'll use a LOT of unique TCP
> connections between the clients and the server. When you're client is
> done with the TCP connection, the socket goes into a FIN_WAIT or
> TIME_WAIT state on the server for quite some time. I've had to tweak
> these kernel settings in the past to get Linux to move sockets out of
> the TIME_WAIT state quickly so socket resources could be reused by new
> connections. This is actually a security feature of Linux (to leave
> sockets in a timewait state for a while), but can affect network
> performance for certain types of applications.
> While your Linux server is serving many clients (100 concurrent if you
> can do that), check to see how many sockets are in a state other than
> netstat -tn | grep -v ESTABLISHED
We're not running under linux right now, but I'll look at that the
next time we are.
> While you're at it, what does your CPU look like when running with 100 clients?
> top -n 1
CPU utilization is low, around 3-5%, although it'll sometimes spike to
15%, and on rare occasions maybe to 30% but only for an instant.
> The fact is that Linux takes longer on Linux with identical hardware
> and software stack (java version 1.x, Jboss version x, etc.) -- right?
> So, we need to find out where you are bound. Are you network bound?
> Are you CPU bound? Are you memory bound? Are you I/O bound?
Yeah, that's what we want to know, and so far it doesn't look like any
of them. The linux box as oodles more memory, same processors,
they're only acting as jboss servers, the win box has a 3-Ware raid
controller, running RAID-5, the linux box has an Adaptec raid
controller, also RAID-5, both servers were purchased from the same
@#()*&$!% so I'm pretty sure they're the same type/size hard drives.
I don't think we've looked at the network in detail yet, but it should
be the same for both,
> Also, as far as Solaris goes -- do you have SATA drives with a BIOS
> RAID? Solaris 10 doesn't support SATA RAID well as far as I can tell.
> I believe your boot problem is related to that. Many newer BIOSes
> allow you to run your SATA drives in a look-like-an-ATA-drive mode.
> This would allow Solaris to see the drive at boot (if this indeed is
> your problem).
Yeah, that sounds like what we have. We'll probably dump the solaris
attempt and go back to linux on this server, so it's not a big deal.
More information about the PLUG