Hallo Bernd (und Lars),
Am 2013-12-10 12:55, schrieb Bernd Walter:
> On Tue, Dec 10, 2013 at 11:47:12AM +0100, Marian Hettwer wrote:
>> Hallo Liste,
>>
>> ich vermute zwar, daß ich am Ende an freebsd-java@ oder
>> freebsd-stable@
>> schreiben muss, aber ich probiers erstmal hier :)
>>
>> ich teste auf Arbeit gerade FreeBSD mit java.
>> Der Cluster in Frage besteht bis jetzt aus 18 Debian Maschinen (Linux
>> 3.2) und meine Versuchskiste wäre die 19. Maschine.
>> Die Kisten sind das Suchbackend einer der größten deutschen
>> kleinanzeigen plattformen.
>> Die Referenzmaschinen (also der bestehende cluster) läuft mit Oracle
>> Java 7u21, tomcat6 und solr 4.6.0.
>> Mein Setup der FreeBSD Maschine ist so identisch wie möglich (OpenJDK
>> 7u25 aus packages installiert, ebenso tomcat6).
>> FreeBSD ist 9.2-REL mit zfs on root (via mfsbsd installiert).
>>
>> Das verwunderliche was ich sehe ist, daß sobald ich etwas load auf die
>> Maschinen gebe, 90% der CPU zyklen auf system cpu verbraucht werden.
>> Das ganze system kommt faktisch zum stillstand.
>
> [...]
>
>> und system cpu explodiert. :-/
>
> System CPU im Prozess klingt nach syscall.
Ja, wobei 250k bis 300k syscalls/s jetzt nicht sooo viel ist.
Also eher langlaufende syscalls.
> Klassiker ist z.B. eine regelmässige Zeitabfrage, die Linux ungenau,
> bei
> SMP nicht mal zwingend immer aufsteigend, liefert und FreeBSD genau mit
> entsprechend mehr CPU-Overhead.
> Populärer Kandidat für excessive (und teilweise sinnfreie, weil
> ungenau)
> Zeitabfragen war früher immer MySQL.
stimmt. Ich erinnere mich da an diverse mail threads.
> Ich weiß aber, dass hier bei FreeBSD ein Workaround für quick and dirty
> time
> existiert - habe mich aber nicht weiter mit auseinander gesetzt.
Muss ich mal googlen. Dass es da einen work around gibt wusste ich
nicht.
> Gggfs. findest du ja was in der Richtung.
> Java selber dürfte sowas nicht machen, aber eventuell euer Java-Code.
Das ist nicht "unser" java code. Das ist solr (lucene.apache.org). Neben
elasticsearch vermutlich die am häufigsten eingesetzte open source such
engine im typischen web umfeld.
> Ansonsten würde ich mal die syscalls per ktrace und Co tracen, um einen
> Eindruck zu bekommen was da passiert.
Ja, ktrace/kdump wollte ich mal ausprobieren.
Bin beim rumsuchen über dtruss gestolpert. Das klingt doch noch mehr
nach was ich suche.
5 Sekunden "dtruss -f -c -o -d -p 32754" dann ctrl c gibt mir folgendes:
CALL COUNT
connect 1
fstat 1
getsockopt 1
kqueue 1
mprotect 1
open 1
socket 1
dup2 2
getsockname 2
accept 3
poll 3
close 4
fcntl 7
setsockopt 9
sendto 11
stat 12
recvfrom 23
read 38
ioctl 39
write 41
kevent 83
_umtx_op 191
pread 12872
sched_yield 17521
Das war wenn die Maschine bei 50% in load balancing noch ordentlich
funktioniert.
Mal schauen was für output es gibt wenn sie "umfällt."
Beste Grüße,
Marian
-- the problem with troubleshooting is that trouble shoots back. To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org with "unsubscribe de-bsd-questions" in the body of the messageReceived on Tue 10 Dec 2013 - 15:25:46 CET