| 1 |
Hallo! |
| 2 |
|
| 3 |
Check mal die Schreib-/Leseperformance bei den betroffenen Stellen. |
| 4 |
Wahrscheinlich braucht schon ein ls ewig? Wenn ein Verzeichnis auf mehrere |
| 5 |
Webserver exportiert wird, dann entsteht schnell ein Flaschenhals durch die |
| 6 |
Zugriffszeiten der Festplatten. Falls das bei Dir der Fall ist, kann es |
| 7 |
helfen, RAM aufzurüsten (hängt von Menge und Art der Daten ab) und ein Raid |
| 8 |
aus vielen _schnellen_ Platten zu benutzen, auch wenn die kleiner sind. |
| 9 |
Wenn auch viele Schreibzugriffe gemacht werden und die Systeme |
| 10 |
ausfallsicher 'genug' sind ;-) kann es einen sehr großen |
| 11 |
Geschwindigkeitszuwachs bringen, NFS von sync auf async umzustellen. |
| 12 |
|
| 13 |
Am Mittwoch, 27. Juni 2007 15:38 schrieb support@××××××.de: |
| 14 |
> Hallo, |
| 15 |
> |
| 16 |
> wir haben folgendes Setup: |
| 17 |
> Ein Rechner (Dual Xeon mit 4GB Ram) hängt via Fibre Channel an einem SAN |
| 18 |
> Ein zweiter identischer Rechner hängt via NFS an Rechner ein. Anbindung |
| 19 |
> über eine dedizierte 1GB Schnittstelle |
| 20 |
> |
| 21 |
> |
| 22 |
> Nun haben wir Rechner 1 teilweise eine hohe Last von > 3, obwohl (noch) |
| 23 |
> kaum Traffic drauf ist (das sind unsere Webserver). Ich schaue mir Top an |
| 24 |
> und sehe: |
| 25 |
> |
| 26 |
> top - 15:35:38 up 144 days, 22:41, 1 user, load average: 3.54, 2.75, 2.34 |
| 27 |
> Tasks: 115 total, 1 running, 114 sleeping, 0 stopped, 0 zombie |
| 28 |
> Cpu0 : 1.3%us, 1.3%sy, 0.0%ni, 2.7%id, 94.0%wa, 0.0%hi, 0.7%si, |
| 29 |
> 0.0%st |
| 30 |
> Cpu1 : 21.7%us, 1.3%sy, 0.0%ni, 75.3%id, 1.7%wa, 0.0%hi, 0.0%si, |
| 31 |
> 0.0%st |
| 32 |
> |
| 33 |
> |
| 34 |
> Oha, IO Wait ist aber groß. Gibt es nun einen Weg zu erkennen, was den |
| 35 |
> Wait so hoch treibt ? |
| 36 |
> |
| 37 |
> Schon mal Danke |
| 38 |
> Stonki |
| 39 |
-- |
| 40 |
gentoo-user-de@g.o mailing list |
Archives