On 3/6/06, Bryan Sant <[EMAIL PROTECTED]> wrote:
> Ok. The system is virtually asleep. I have a new request then.
>
> When you get a chance to run your app in Linux under some load execute:
This is not under load, but the poor performance is manifest with just one user.
Oh, and by the way, this is now different hardware, a 32bit install,
with only 2GB RAM total, -Xmx1408m, but the problem is exists.
> uptime
19:40
> vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 585448 91132 907528 0 0 2 6 67 28 0 0 100 0
> netstat -s
Ip:
1559213 total packets received
24 with invalid addresses
0 forwarded
0 incoming packets discarded
1559129 incoming packets delivered
1324626 requests sent out
90 reassemblies required
30 packets reassembled ok
Icmp:
14182 ICMP messages received
14180 input ICMP message failed.
ICMP input histogram:
echo requests: 2
2 ICMP messages sent
0 ICMP messages failed
ICMP output histogram:
echo replies: 2
Tcp:
508 active connections openings
172 passive connection openings
0 failed connection attempts
14 connection resets received
83 connections established
1476735 segments received
1324213 segments send out
60 segments retransmited
0 bad segments received.
7 resets sent
Udp:
4843 packets received
0 packets to unknown port received.
14 packet receive errors
432 packets sent
TcpExt:
39 packets pruned from receive queue because of socket buffer overrun
ArpFilter: 0
411 TCP sockets finished time wait in fast timer
1 time wait sockets recycled by time stamp
70992 delayed acks sent
4 delayed acks further delayed because of locked socket
Quick ack mode was activated 210 times
18211 packets directly queued to recvmsg prequeue.
3600 packets directly received from backlog
42464 packets directly received from prequeue
1072820 packets header predicted
111 packets header predicted and directly queued to user
TCPPureAcks: 21212
TCPHPAcks: 914601
TCPRenoRecovery: 0
TCPSackRecovery: 0
TCPSACKReneging: 0
TCPFACKReorder: 0
TCPSACKReorder: 0
TCPRenoReorder: 0
TCPTSReorder: 0
TCPFullUndo: 0
TCPPartialUndo: 0
TCPDSACKUndo: 0
TCPLossUndo: 4
TCPLoss: 0
TCPLostRetransmit: 0
TCPRenoFailures: 0
TCPSackFailures: 0
TCPLossFailures: 0
TCPFastRetrans: 0
TCPForwardRetrans: 0
TCPSlowStartRetrans: 0
TCPTimeouts: 25
TCPRenoRecoveryFail: 0
TCPSackRecoveryFail: 0
TCPSchedulerFailed: 0
TCPRcvCollapsed: 2339
TCPDSACKOldSent: 210
TCPDSACKOfoSent: 0
TCPDSACKRecv: 0
TCPDSACKOfoRecv: 0
TCPAbortOnSyn: 0
TCPAbortOnData: 3
TCPAbortOnClose: 3
TCPAbortOnMemory: 0
TCPAbortOnTimeout: 6
TCPAbortOnLinger: 0
TCPAbortFailed: 0
TCPMemoryPressures: 0
> top -n 1
top - 12:06:08 up 19:51, 5 users, load average: 0.02, 0.02, 0.06
Tasks: 106 total, 1 running, 105 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.2% us, 0.0% sy, 0.0% ni, 99.7% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2074672k total, 1490552k used, 584120k free, 91132k buffers
Swap: 1052248k total, 0k used, 1052248k free, 907528k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
12997 root 17 0 1788m 382m 89m S 2.0 18.9 3:17.09 java
1 root 16 0 692 268 224 S 0.0 0.0 0:01.35 init
2 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT 0 0 0 0 S 0.0 0.0 0:00.01 migration/1
5 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
6 root RT 0 0 0 0 S 0.0 0.0 0:00.02 migration/2
7 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2
8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
9 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/3
10 root 10 -5 0 0 0 S 0.0 0.0 0:00.15 events/0
11 root 10 -5 0 0 0 S 0.0 0.0 0:00.04 events/1
12 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 events/2
13 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 events/3
14 root 10 -5 0 0 0 S 0.0 0.0 0:00.01 khelper
15 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
33 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
> netstat -tn | grep -v ESTABLISHED
Nothing.
> I think when you run the above commands (please send the output of
> each) we're going to find out that the CPU is waiting on something
> most of the time. My guess is that you are hitting your kernel's
> currently set TCP/IP stack limits on max open TCP connections and the
> TIME_WAIT problem I described before is the issue -- or -- for
> whatever reason, you're JDBC connection to the MSSQL server isn't
> retrieving data as fast as the 2K3 server is.
>
> -Bryan
/*
PLUG: http://plug.org, #utah on irc.freenode.net
Unsubscribe: http://plug.org/mailman/options/plug
Don't fear the penguin.
*/
