Re: [OT] Apache 32bit vs 64bit
Am Mittwoch, den 03.09.2008, 14:39 +0200 schrieb Jochen Schulz:
> Thomas Halinka:
> > Am Mittwoch, den 03.09.2008, 11:54 +0200 schrieb Jochen Schulz:
> >>
> >> Wachstum? Meinst Du mehr Traffic? Macht der Server noch was anderes
> >> (also auch Webanwendungen)? -Mit dem Ausliefern statischer Daten
> >> bekommt man doch keinen Server mehr ausgelastet....
> >
> > Hmm okay, es handelt sich hierbei allerdings um eine Shopanwendung, die
> > aktuell ca 900 conncurrents bedient. diese 900 concurrents kosten mich
> > aktuell ca 5GB und ca 70%-CPU.
>
> Ich behaupte aber weiterhin, dass der Apache von diesen 70% nur einen
> Bruchteil ausmacht. Da kommst Du nicht viel weiter.
# uptime
15:48:53 up 43 days, 18:49, 1 user, load average: 3.76, 3.06, 2.68
Cpu(s): 45.7% us, 1.1% sy, 0.0% ni, 52.8% id, 0.0% wa
und da ist grad wenig los, idR liegt der Load > 6 und CPU ca 70%
Och nö, du hast Recht, denn
# ps -eo rss,args --sort rss | grep apache | awk '{ SUM += $1} END
{ print SUM/1024 }'
204.574
# ps -eo rss,args --sort rss | grep SHOP | awk '{ SUM += $1} END { print
SUM/1024 }'
2169.86
# ps -eo rss,args --sort rss | grep SHOPH | awk '{ SUM += $1} END
{ print SUM/1024 }'
2143.28
>
> Möglichkeiten beim Apache:
sind ja nun nicht mehr interessant :(
>
> Bei dem Shopsystem selbst:
>
> - DB auf andere Maschine auslagern (falls nicht sowieso geschehen).
[x] done
>
> - Caching-Möglichkeiten. (SCheinst Du ja mit dem Reverse-Proxy schon zu
> probieren, aber kann Deine Anwendung das nicht?)
Ne, leider kann diese das nicht :(
> - Anzahl der Hits auf den Application Server reduzieren (AJAX-Spielzeug,
> serverseitige Includes, Checkout-Prozess...)
Momentan ist Application-Server = Webserver. DB und Reverse-Proxy laufen
separiert
>
> - Wie schon von Dir selbst vorgeschlagen: mehr Server für den Shop, mit
> Loadbalancer davor (falls Deine Anwendung sowas nicht mitbringt, ist
> hier der Fall). Der Loadbalancer muss wahrscheinlich schlau genug
> sein, die selben Clients immer auf die selben Server zu schicken. Das
> können die aber Regelfall.
Die Anwendung kann es dank einem CGI, ja - varnish ebenso
>
> - Mit Profiling die lange dauernden Sachen ermitteln und die optimieren.
> Das ist natürlich auf einem Produktivsystem schwer (und auf einem
> Testsystem hat man keine reale Last), ich kenne das.
Wie meinst du das Profiling? Bin da nicht so bewandert....
>
> Versuche auf jeden Fall auch genau zu ermitteln, welche Komponente das
> Bottleneck ist. Ist das wirklich die CPU, oder vielleicht doch
> Platten-I/O?
CPU auch nicht wirklich
# vmstat
procs -----------memory---------- ---swap-- -----io---- -system--
----cpu----
r b swpd free buff cache si so bi bo in cs us sy
id wa
1 0 133900 1178072 1202936 2819448 1 0 0 1 1 1 15
3 82 0
Die dreht nur Däumchen....
>
> > Auf 64Bit lag der Speicherverbraucht (bei glicher Besucherzahl bei >7GB
> > RAM)
>
> Autsch. Was für eine Plattoform? Java?
Ne, C - das ist ja der Hammer.
> >> ... Wenn Du auf dem Server auch eine Webanwendung hinter dem Apache hast,
> >> ist mit allerhöchster Wahrscheinlichkeit nicht der Apache der
> >> Flaschenhals. Kümmere Dich um die Anwendung, nicht (so sehr) um den
> >> Apache.
> >
> > Hmm, das ist wohl war, handelt es sich bei dieser Anwendung noch um ein
> > Verbrechen aus der Vergangenheit....
>
> Same here. Aber je länger man selbst dabei ist, desto weniger kann man
> seine Hände in Unschuld waschen. :)
Ich bin erst seit einigen Tagen mit bei und deshalb erstmal
unschuldig ;)
>
> >> Um was für Server soll es überhaupt gehen? Professionelle Serverhardware
> >> gibt es doch kaum noch in 32 Bit, oder irre ich da?
> >
> > Ja klar, aber ich werde XEN nutzen. Und da stellte sich mir aktuell die
> > Frage, ob ich nun 3 Apache domU mit je 4GB als i386 laufen lasse oder
> > lieber eine fette domU mit amd64 und 12GB RAM.
>
> Du könntest alternativ auch eine i386 mit 12GB RAM verwenden, sofern
> Deine einzelnen Prozesse nicht mehr als 4GB brauchen. Ich denk auf jeden
> Fall nicht, dass Du durch das Aufteilen der Hardware in mehrere VMs
> etwas gewinnst.
Hmm, die einzelnen Prozesse belegen nicht soviel RAM nur eben in der
Summe:
# ps -eo rss,args --sort rss | grep SHOP | wc -l
555
# ps -eo rss,args --sort rss | grep SHOPH | wc -l
559
> > unter i386 ca 5GB RAM-Verbrauch
> > unter amd 64 > 7GB Ram-Verbrauch
>
> In einem einzigen Prozess!?
ne die Summe aller beteiligten "Shop/www-Prozesse"
>
> J.
Grüße
Thomas
Reply to: