Re: tomcat java system cpu usage

Hi Bernd,

Am 2013-12-11 14:27, schrieb Bernd Walter:
> On Wed, Dec 11, 2013 at 11:30:50AM +0100, Marian Hettwer wrote:
>> 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.
>

Das wäre sehr schade. Ich bin auch ein Fan von ZFS.
Könnte ich nicht alternativ das solr datadir (dort werden die reads wohl
sein) auf ein memory filesystem schieben?
Die Kiste hat 64GB RAM. Das ist weit weit mehr als ich da jemals
brauchen würde...

>> 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.
>

Ich fass das erstmal nicht an. Ich denke es ist eher eine
Folgeerscheinung.

>> 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.

Interessant. Wir haben ZFS unter Solaris 10 auf MySQL servern seit
Jahren im Einsatz. Und IO Probleme gibt es da an sich nicht.
Wir sind sogar so mutig und benutzen auf einigen MySQL read slaves
ZFSonLinux (kernel modul). Und das tut gut..

> 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.

Nunja, der solr index in dem solr rumsucht ist immerhin 7GB groß. Das
mit den pread sachen macht da schon sinn..

Ich guck mal ob ich die lesenden use cases auf ein mfs bekommen kann.
Damit wäre ZFS ja raus...

Grüße,
Marian

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Thu 12 Dec 2013 - 10:52:00 CET