Re: tomcat java system cpu usage

From: Bernd Walter <ticso(at)cicely7.cicely.de>
Date: Wed, 11 Dec 2013 14:27:49 +0100

On Wed, Dec 11, 2013 at 11:30:50AM +0100, Marian Hettwer wrote:
> Am 2013-12-10 18:53, schrieb Oliver Fromme:
> >Eine Ferndiagnose ist bei solchen Dingen schwierig. Es kann
> >alles Mögliche sein.
> >
> >Als erstes würde ich ein Update auf stable/10 versuchen. Es
> >gibt da eine Reihe von Verbesserungen, die insbesondere auch
> >hochparallele Systeme betreffen (und hw.ncpu=32 ist ja schon
> >eine ganze Menge). Einen Versuch ist es wert.
> >
> freebsd-update auf das letzte 10-BETA oder besser make world und auf
> 10-stable?
>
> 10-BETA1 hatte ich schonmal probiert und das zeigte das selbe verhalten.
> Also vermutlich doch ab auf 10-stable...
>
> 32 CPU's gehört hier mittlerweile zu unserer standard hardware. Und für
> solr sogar sehr gut geeignet, weil solr komplett über die Menge an CPU's
> skaliert. (zumindest unter Linux *grmbl*).

Kann ich verstehen.
Bekommt man ja auch nicht kleiner, wenn man RAM reinstecken will.

> >Ich fasse mal Deine Beschreibung zusammen: Bei 50% Last (im
> >Vergleich zum Linux-System) ist noch alles in Ordnung, bis
> >auf geringfügig längere Antwortzeiten. Bei 100% Last dagegen
> >läuft es komplett aus dem Ruder und die Antwortzeiten gehen
> >massiv nach oben, bzw. die Kiste scheint zu "stehen".
> >
>
> Ganz genau. Wenn wir Last definieren als Menge and requests pro Sekunde.
> Volle Last vom load balancer wären 90 bis 120 req/s, abhängig von der
> Tageszeit.
> Ein vergleichbares Linux system ist dann bei einer CPU load von 10 bis
> 15 CPU's.

90-120 mit Java ist ordendlich.

> Ein paar details zum disk backend:
> Dec 5 13:07:02 ksolr47-10 kernel: ciss0: <HP Smart Array P220i> port
> 0x4000-0x40ff mem 0xf7d00000-0xf7dfffff,0xf7cf0000-0xf7cf03ff irq 34 at
> device 0.0 on pci3
> Dec 5 13:07:02 ksolr47-10 kernel: ciss0: PERFORMANT Transport
> Dec 5 13:07:02 ksolr47-10 kernel: da0 at ciss0 bus 0 scbus0 target 0
> lun 0

Die Teile sind von den IO-Zahlen her meiner Erfahrung nach vollkommen OK.

> zpool status
> pool: tank
> state: ONLINE
> scan: none requested
> config:
>
> NAME STATE READ WRITE CKSUM
> tank ONLINE 0 0 0
> da0p3 ONLINE 0 0 0

Hier wird es aber extrem spannend.
Oliver ist ja Fan von ZFS, ich bin es kein Stück.
ZFS hat nette Features, aber das mit der Performance ist regelmässig
ernüchternd.
Ich kann mir extrem gut vorstellen, dass ZFS für schlechte pread-Werte
verantwortlich ist.
Du solltest es zumindest mal mit einem reinen UFS-System vergleichen.

> errors: No known data errors
>
> NAME USED AVAIL REFER MOUNTPOINT
> tank 13.4G 955G 31K none
> tank/root 13.4G 955G 1.59G /
> tank/root/tmp 86K 955G 86K /tmp
> tank/root/var 11.8G 955G 11.8G /var
>
>
> Interessant unter Umständen ist noch folgender Output aus
> /var/log/messages:
>
> Dec 10 10:31:06 ksolr47-10 kernel: sonewconn: pcb 0xfffffe0978ea4310:
> Listen queue overflow: 151 already in queue awaiting acceptance
> Dec 10 10:31:14 ksolr47-10 last message repeated 401 times
> Dec 10 10:32:15 ksolr47-10 last message repeated 108 times
> Dec 10 14:35:37 ksolr47-10 kernel: sonewconn: pcb 0xfffffe0978ea4310:
> Listen queue overflow: 151 already in queue awaiting acceptance
> Dec 10 14:36:02 ksolr47-10 last message repeated 981 times

Das kann ein Folgefehler sein, weil zu langsam abgearbeitet wird.
Kann aber auch sein, dass du defaults hoch setzen musst.
Auf jeden Fall verlierst du Verbindungen, wenn das passiert.
Die Listenqueue wird beim Listen-Aufruf bestimmt und hat ein sysctl
Maximum, was default auf 128 steht.
Normalerweise belässt ein schnell reagierender Server niemals lange
Verbindungen in der Queue - Sonderanwendungen mal ausgenommen.

> Von den Uhrzeiten war das jeweils wenn ich den 2. Load Balancer dazu
> geschaltet habe und daher von 50% traffic auf 100% traffic gegangen bin.
> Ich würde aber eher annehmen, daß diese Meldung eine Folgeerscheinung
> des "umfallens" sind. Die Maschine wird lahm, weil sie Ihre Zeit in
> syscalls verbringt, varnish als load balancer leitet aber weiter traffic
> hin und irgendwann ist der tomcat voll (http connector mit 1024
> maxthreads).

Sehe ich auch so.

> Interessanter ist finde ich folgender Eintrag:
> Dec 10 19:46:20 ksolr47-10 kernel: pid 32754 (java), uid 80: exited on
> signal 5
>
> Meine Testmaschine war weiter 50% im load balancing. Ab 18 Uhr wird der
> traffic stärker. Scheinbar explodierte dann letztendlich die jvm.
> SIGTRAP. Soso. Das habe ich noch nicht gesehen. Ich frage mich wo er den
> core hingeworfen hat. Nicht in /usr/local/apache-tomcat* und nicht in
> /var/tmp.
>
>
> >Was läuft denn auf dem Rechner noch so? Ein Paketfilter (PF,
> >IPFW)? Dummynet? NFS? Sonst irgendwas Spezielles?
> >
>
> Nichts spezielles. War ne default installation basierend auf mfsbsd.
> Zusätzlich zum tomcat läuft lediglich openntpd für Zeit und munin für
> graphen. Sonst nix.
> Packet filter habe ich nicht konfiguriert, also sollten die ja aus sein.
>
> meine rc.conf:
>
> zfs_enable="YES"
> sshd_enable="YES"
> hostname="xxx.xxx.xxx"
> defaultrouter="10.xxx.xxx.xxx"
> ifconfig_ix0="UP"
> ifconfig_ix1="UP"
> cloned_interfaces="lagg0"
> ifconfig_lagg0="laggproto failover laggport ix0 laggport ix1
> 10.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"
>
> # ports
> openntpd_enable="YES"
> munin_node_enable="YES"
> tomcat60_enable="YES"
> tomcat60_java_version="1.7+"
> tomcat60_catalina_log=">> /var/log/tomcat-server/catalina.log 2>>
> /var/log/tomcat-server/catalina.err"
> tomcat60_java_opts="-Xms4000m -Xmx4000m"
>
>
> Soweit so gewöhnlich, oder?

lagg benutze ich eher nicht, da kann ich nicht viel zu beitragen.
Der Rest sieht normal aus, bis auf den ZFS, was ich für so eine
Anwendung (aus allgemeiner Erfahrung heraus) niemals benutzen würde.
Ob ZFS in dem konkreten Fall eine Rolle spielt kann ich nicht sagen.
pread spricht jedenfalls dafür, dass du irgendeine Art von Datenbank
darauf betreibst und damit kommt ZFS selten gut zurecht.
Immerhin ist es lesend, sonst hätte ich empfohlen noch mal nach der
Blocksize zu schauen, was aber eher schreibend eine Rolle spielt.
Ich nehme mal an, dass ZFS noch reichlich freien Platz hat.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 11 Dec 2013 - 14:28:08 CET

search this site