Hilfe! Der ram ist voll und ich weiss nicht wieso

Hilfe! Der ram ist voll und ich weiss nicht wieso (47 Beiträge, 649 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Wir haben einen Server in den USA stehen auf dem ein Forum läuft, das mittlerweile eine ziemlich grosse (1,7GB) MySQL-Datenbank laufen hat. Die Maschine ist ein P4 2Ghz mit 1GB Ram. Das Problem ist, daß die Maschine in letzter Zeit ständig die fast komplette RAM zugebuttert hat und diese nicht mehr freigibt. Zumindest interpretiere ich die Ausgabe von "top" so.


110 processes: 108 sleeping, 2 running, 0 zombie, 0 stopped
CPU states: 40.5% user, 15.0% system,  0.0% nice, 44.4% idle
Mem:  1033496K av, 1016316K used,   17180K free,       0K shrd,    6680K buff
Swap: 2064344K av,    3492K used, 2060852K free                  821868K cached

Wir vermuten, daß die Datenbank daran Schuld ist, daß der Ram zugebuttert ist, aber selbst wenn wir diese runterfahren, wir die ram nicht geleert und bleibt voll.

Die performance der maschine ist natürlich in unter jeder sau und unser Forum (durchschnittlich 300 aktive Benutzer gleichzeitig) ist kaum verwendbar.

Wie kann das sein? Dazu kommt noch, daß wenn ich die Ausgabe von top nach Memory ('M') sortiere und die ersten 70 Werte von "SIZE" (das ist doch der richtige Wert oder?) zusammenzähle komme ich nicht mal auf 500Mb. Was ist da faul?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

sorry aber bei durchschnittlichen 300 Benutzern online, und 1.7 Gb DB sind 1 Gbyte Ram einfach unterdimensioniert.

Current PC: Dual Athlon MP 2800+ @ 16*146*2 = 4672Mhz = ~ 7200+ , TYAN S2466N 760MPX, 2048 MB Samsung DDR ECC Reg CL2, IBM Hitachi 7k250 120 GB HDD, ATI FireGL X2 (R9800MOD),Soundblaster Audigy,8x DVD Brenner Liteon, Samsung Syncmaster 957p, Samsung Syncmaster 750p, Wacom Graphire 3 Studio, CM Centurion Silver, Tagan 380Watt

Jop kann Speed nur beipflichten... Hau ihm am besten noch einen Gig rein...

MfG Akilae

Public: server.rawclan.at:27016

Das kanns doch nicht wirklich sein, daß man soviel speicher haben muß wie die DB groß ist, oder? Ein weiteres Problem ist, daß nur noch max. 512mb reinpassen in die Kiste und die Herren, die uns hosten 19$/Monat dafür möchten. Außerdem kommt mir vor, daß da irgendwas anderes faul ist, weil, wie gesagt, die top70 der top nichtmal die hälfte des Speichers zubuttert.

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Ich fürchte du täuscht dich hier!

Von dem 1GB sind ja rund 800MB cached!
D.h. die Maschine hat mehr als genug RAM.
Und bevor dieser zu rosten beginnt, verwendet Linux ihn eben als Cache.

kannst du mir das bitte erklären? Was heisst 800mb sind gecached?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Na das was man unter Cache eben versteht.
Bevor ein Block nochmals physisch von der Platte gelesen wird, sucht man ihn vorher im Cache und gewinnt damit Performance.

PS: Welchen Kernel verwendest du?

uname -r gibt 2.4.27 zurück. Die Sache ist nun, wenn es weder der Speicher noch die CPU ist, was ist es dann? Ist es die Festplatte?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Laß doch mal

vmstat 5

eine Zeit lang laufen.
Lt. Doku dürfte dein Kernel die Option "-a" bei vmstat noch nicht unterstützen.
Versuch es dennoch diese Option anzugeben.
Diese zeigt die das Verhältnis zwischen "active/inactive" Memory an.

Also:

vmstat -a 5

vmstat zeigt dir unter anderem auch die I/Os und die CPU-Auslastung.

danke, vmstat läuft gerade. die -a option kennt das Programm wirklich noch nicht.

was cached das System im Speichercache und sollte das System den speicher nicht freigeben und cache leeren, wenn speicher für applikationen benötigt wird?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

> was cached das System im Speichercache

Bereits gelesene Blocks.

> und sollte das System den speicher nicht freigeben und cache leeren, wenn
> speicher für applikationen benötigt wird?

Ja klar. Wennst jetzt 100 (verschiedene) Programme starten würdest, würde sich auch der Cache-Anteil reduzieren.

Also ich seh da kein Problem, sowas darf man nicht wie bei Windows sehen.
Linux ist so konstruiert, dass es immer möglichst viel RAM beansprucht, weil der ja im vergleich zur Festplatte viel schneller ist.
Unter Windows versucht immer jeder möglichst viel RAM frei zu haben, was ja eigentlich sinnlos ist, da die Daten dann ausgelagert werden.

Viel RAM ist tatsächlich nicht mehr verfügbar, ich würd mal schaun welcher Prozess diesen Speicher beansprucht.
Negativ ist das wie gesagt, nicht.
------
Dr. Watson

> Viel RAM ist tatsächlich
> nicht mehr verfügbar, ich würd mal schaun welcher Prozess diesen Speicher
> beansprucht.Negativ ist das wie gesagt, nicht. ------

Kannst du mir vielleicht genau sagen wie ich das anstellen kann? Weil, wenn ich bei top nach M sortiere und bei den ersten 70 Zeilen die SIZE zusammenzähle, dann komme ich nicht mal auf die hälfte der verwendeten Ram.

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

$ vmstat -a
Zeigt an, wieviel Speicher aktiv und inaktiv ist, Versuchs mal.

Bei meinem kleinen Webserver sind die 512MB RAM übrigens auch ständig voll belegt, bis auf ein paar MB, und auf dem läuft nahezu nichts..
------
Dr. Watson

mach 1GB swap oder last mehr speicher reinstopfn

Er hat ja bereits 2GB Swap

und die werden praktisch nicht verwendet.

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

eben, dass must du ändern, der muss früher zum swapen beginnen

Weisst du wie ich das machen kann?

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

welches os hast da drauf? und wo läuft der server

Du solltest ihm aber schon irgendwie mitteilen, daß du ihn gerade verarscht!

Seh ich auch so

Warum sollte man Daten absichtlich ins (langsame) Swap File verlagern, wenn sie auch im schnellen RAM Platz haben?
------
Dr. Watson

KKH´s Performance-Optimierungs-GuideLines empfehlen wahrscheinlich auch, das Swap-File nach /dev/fd0 zu legen.

ich sag einfach mal er braucht mehr platz und zur not soll er swapen (is schon klar das es langsam is) weil ich nicht weis, wer sein abieter ist und wie es dort mit nem ipgrade aus.

ich hab zwar kein swap-file auf ner floppy, aber nen apache schön (was so ne kleine floppy alles kann) hihi

> ich sag einfach mal er braucht mehr platz und zur not soll er swapen (is schon
> klar das es langsam is) weil ich nicht weis, wer sein abieter ist und wie es
> dort mit nem ipgrade aus.

Irgendwie hab ich den Eindruck, du sendest deine Beiträge mit einem breiten ironischen Grinsen drauf und meinst das Ganze gar nicht ernst.

Falls ich doch irre - eine kleine Zusammenfassung:

- er hat 2GB Swap-Space der völlig brach liegt.
- er hat 1GB Memory der zu 80% als Cache verwendet wird.
- er hat KEIN Memory-Problem

Das wär aber krank!
So nach dem Motto, hilfe mein Computer läuft zu schnell. Wie klann ich ihn am besten ausbremsen.

es is besser er swapped wie er steht und der speicher ist voll. und so schlecht ist das swapppen nicht wenn die hardware passt. ein freund von mir lässt auf ne scsi platte swapen is eigentlich recht flott.

und außer speicher upgraden oder swapen bleibt nicht viel

Nochmals!
Diese Maschine hat mehr als genug Speicher!
Dass der nicht das Problem ist, ist das einzige was sicher ist.

Du suchst an der falschen Stelle!

Wenn die MEM Zeile sehr viel anders aussschauen würde, tät ich mir Sorgen machen.

Was aber enorm ist, ist die CPU Last die User Prozesse machen.
Gib mal die gesamte Ausgabe von Top, dann sieht man wer der Übeltäter ist.

top gibt folgendes aus:


 3:23pm  up  4:40,  2 users,  load average: 3.92, 3.79, 2.86
127 processes: 118 sleeping, 9 running, 0 zombie, 0 stopped
CPU states: 49.7% user, 16.3% system,  0.0% nice, 33.9% idle
Mem:  1033496K av, 1010584K used,   22912K free,       0K shrd,    5316K buff
Swap: 2064344K av,   22572K used, 2041772K free                  723028K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
19618 apache    14   0 11016 8680  5516 R     5.1  0.8   0:03 httpd
19278 apache     9   0 11452 9120  5536 S     4.6  0.8   0:05 httpd
17710 apache    15   0 12376 9.8M  5524 S     3.4  0.9   0:09 httpd
17624 apache    13   0 11448 9136  5556 S     3.2  0.8   0:08 httpd
20052 apache    15   0 12180 9904  5584 R     3.2  0.9   0:02 httpd
19705 apache    15   0 12388 9.8M  5448 R     3.0  0.9   0:02 httpd
19844 apache    15   0 11956 9528  5424 R     3.0  0.9   0:02 httpd
18207 apache     9   0 11860 9544  5556 S     2.9  0.9   0:09 httpd
17921 apache    10   0 11928 9672  5608 S     2.2  0.9   0:08 httpd
18177 apache    12   0 11512 9192  5548 S     2.2  0.8   0:09 httpd
19747 apache    15   0 12024 9684  5524 R     2.0  0.9   0:01 httpd
20743 root      16   0  1116 1116   836 R     1.7  0.1   0:00 top
17719 apache     9   0 11572 9316  5608 S     1.5  0.9   0:11 httpd
20644 apache     9   0 11380 8996  5508 S     1.3  0.8   0:00 httpd
17309 apache    10   0 11492 9236  5604 S     1.2  0.8   0:11 httpd
19845 apache     9   0 12044 9708  5520 S     1.0  0.9   0:01 httpd
18732 apache     9   0 11704 9388  5556 S     0.8  0.9   0:06 httpd
20781 mysql     10   0 85040  79M  1236 S     0.8  7.9   0:00 mysqld
20487 apache     9   0 10420 8044  5528 S     0.5  0.7   0:01 httpd
18326 apache     9   0 11708 9532  5524 S     0.3  0.9   0:07 httpd
19486 apache    10   0 11396 9124  5572 S     0.3  0.8   0:02 httpd
19602 apache     9   0 11676 9308  5540 S     0.3  0.9   0:02 httpd
20511 apache     9   0 10148 7760  5524 S     0.3  0.7   0:00 httpd
20586 apache     9   0 10608 8120  5412 S     0.3  0.7   0:00 httpd
20639 apache     9   0 10380 7872  5376 S     0.3  0.7   0:00 httpd
20785 mysql     12   0 85040  79M  1236 S     0.3  7.9   0:00 mysqld
20788 mysql     15   0 85040  79M  1236 R     0.3  7.9   0:00 mysqld
20790 mysql     19   0 85048  79M  1236 R     0.3  7.9   0:00 mysqld
17592 apache     9   0 11844 9688  5460 S     0.1  0.9   0:11 httpd
18039 apache     9   0 11936 9608  5548 S     0.1  0.9   0:09 httpd
18250 apache     9   0 11628 9388  5468 S     0.1  0.9   0:06 httpd
18800 apache     9   0 11860 9600  5604 S     0.1  0.9   0:04 httpd
19484 apache     9   0 11792 9452  5536 S     0.1  0.9   0:03 httpd
19736 apache    10   0 11416 9144  5588 S     0.1  0.8   0:01 httpd
20571 apache     9   0 11384 9008  5540 S     0.1  0.8   0:00 httpd
20585 apache     9   0  7364 4340  4068 S     0.1  0.4   0:00 httpd
20784 mysql     11   0 85040  79M  1236 S     0.1  7.9   0:00 mysqld
20786 mysql     12   0 85040  79M  1236 S     0.1  7.9   0:00 mysqld

(not sigkilled v1.1 (everyday): no images at all had 0 bytes of wasted capacity)

Da ist ein zu hoher load.
Und der ist fast nur von apache Prozessen.

Ich würde mal die maximale Zahl an kongruenten Clients heruntersetzen.

MaxClients 50 bis 100

tät ich mal probieren.
Ev. mit
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15

Spielen. Falls die Seiten php sind, was geht auf statische Seiten umstellen, um die Ausführzeit zu reduzieren. Ev. sind auch die sql Queries optimierungswürdig, wenngleich nicht die Datenbank den load macht, sondern der Webserver.

Zähl mal wieviele kongruente User du da tatsächlich drauf hast.

ps aux|grep httpd| wc -l

Schau ob das mit den pagehits zusammenpasst, vielleicht greift ja wer die Kiste an.

Das Problem ist auf jedenfall der apache.

> wenngleich nicht die Datenbank den load macht, sondern der Webserver.

Woran erkennst du das?

Weil der Load sich dadurch bestimmt, wieviele Prozesse in der Queue auf Abarbeitung warten.

Wenn man jetzt mit top sieht, dass die Prozesse die am meisten Rechenzeit belegen allesamt apache Prozesse sind, dann ist klar, dass die der Übeltäter sind.

Ähhhmmm - wenn sie Rechenzeit bekommen, veringern sie ja die Grundlage für einen hohen "load" innerhalb eines Intervalls.
Wenn ich dagegen 100 Prozesse habe, die alle auf IO warten, bekommen diese weniger CPU-Leistung, erhöhen damit aber die Anzahl der Prozesse die innerhalb dieser Zeitspanne "gecheckt" werden.

Ich schätze, man bräuchte mehr als den "top" um die Ursache für den recht hohen "load" zu finden.

Wär auch interessant, ob es sich hier um ein SCSI oder IDE-System handelt.
Vielleicht tät schon "hdparm" (falls IDE) einiges optimieren.

Deine Theorie stimmt nicht. Programme ie auf eine Eingabe warten schlafen, und beanspruchen keinen Platz in der runqueue.

Du kannst less in 100 virtuellen Consolen starten, und es wird den load nicht erhöhen, und auch nicht in top aufscheinen. Den Load beeinflussen tatsächlich nur Prozesse die den Prozessor angefordert haben. Und wartende Prozesse tun das nicht.

Ich seh also in top sehr wohl, welche Prozesse für den load verantwortlich sind.
Warum sie allerdings die CPU so beanspruchen lässt sich daraus nicht erkennen.

Schlechte Diskperformance kann allerdings tatsächlich Ursache eines hohen loads sein, allerdings nicht weil Prozesse auf I/O Vorgänge warten, sondern weil diese so endlos brauchen, und den Prozessor binden. Nur in diesem Fall ist das weniger wahrscheinlich. Denn da müssten die Ausführungszeiten für die Datenbankoperationen sehr viel stärker betroffen sein, als die der Apacheprozesse.

Okay - einigen wir uns vielleicht auf folgende Aussagen:

Prozesse die tatsächlich "schlafen" (less ohne auf eine Taste zu drücken) beeinflußen den "load" nicht.

Prozesse die ständig zwischen "sleep" und "active" wechseln, benötigen weniger CPU-Zeit, aber erhöhen den "load".

EIN Prozess mit viel CPU-Leistung erhöht nicht den "load"-Faktor.

Mit anderen Worten - es gibt keinen kausalen Zusammenhang zwischen CPU-Anspruch und "load"-Faktor.

Was meinst du?

Nein, der load ist in direktem Zusamm,enhang mit der CPU Verfügbarkeit.

Dem activen Prozess gehört die ganze CPU. Egal ob er sie Produktiv beschäftigt, oder nicht. Die CPU Last ist für die Systemperformance relativ gleichgültig.

Alleine die Zeit die ein Prozess die CPU bindet ist für die Gesamtperformance wesentlich.
So ist es kein Problem Systeme zu finden, die mehr als 80% CPU idle haben, aber aufgrund eines loads von 6 und größer praktisch tod sind, und auf keine Eingabe mehr reagieren.

> So ist es kein Problem Systeme zu finden, die mehr als 80% CPU idle haben,
> aber aufgrund eines loads von 6 und größer praktisch tod sind, und auf keine
> Eingabe mehr reagieren.

Genau darum geht es ja.
Die Grundlage für "load average" ist die Anzahl der aller Prozesse mit den states "running" und "uninterruptable"
Im "ps" als "R" und "D" erkennbar.

aus: "kernel/timer.c"

/* Nr of active tasks - counted in fixed-point numbers */
static unsigned long count_active_tasks(void)
{
return (nr_running() + nr_uninterruptible()) * FIXED_1;
}

static inline void calc_load(unsigned long ticks)
{
unsigned long active_tasks; /* fixed-point */
static int count = LOAD_FREQ;

count -= ticks;
if (count < 0) {
count += LOAD_FREQ;
active_tasks = count_active_tasks();
CALC_LOAD(avenrun[0], EXP_1, active_tasks);
CALC_LOAD(avenrun[1], EXP_5, active_tasks);
CALC_LOAD(avenrun[2], EXP_15, active_tasks);
}
}

aus "man ps":

PROCESS STATE CODES
D uninterruptible sleep (usually IO)
R runnable (on run queue)
S sleeping
T traced or stopped
W paging
X dead
Z a defunct ("zombie") process

Wobei es so ist, daß Prozesse die auf IO´s von Character-Devices warten, auf "S" gestellt, und solche die auf IO´s von Block-Devices warten auf "D" gesetzt werden.

Daher sehe ich keinen direkten Zusammenhang, zwischen "CPU%" und "load average" - wie du selber ja auch festgestellt hast - im o.a. Beispiel.
Am Beispiel des OP könnte man also auch sagen, daß die "mysqld" wenig "CPU%" aufweisen, aber ständig zwischen den States "R" und "D" wechseln und damit auch den "load" erhöhen. Ob das nun auch wirklich so ist, kann man mit einem zufälligen Auszug aus "top" natürlich nicht feststellen.
Daher auch meine ursprüngliche Frage "woran erkennst du das?"

CPU% ist eine ziemlich unnütze Größe.

In einem Multitaskingsystem ist es mior ziemlich egal, wie die CPU Auslastung ausschaut, sondern nur wichtig, dass mein Prozess Rechenzeit bekommt.

Und dafür ist der load die Aussagekräftige Größe.

Und im Prinzip hast du Recht, dass ein einmaliger Blick auf top nicht unbedingt aussagekräftig ist. Wenn ich allerdings *TRÖT*setze, -was meistens der Fall ist- dass das gepostete Bild typisch ist, und nicht 3 sekunden später nur mehr mysql Prozesse in den top aufscheinen, dann ist offensichtlich, dass das Problem bei den Apacheprozessen zu suchen ist.

Der Verdacht, der von japh geäussert wurde, dass die Apache so viel Rechenzeit belegen, weil die Bandbreite zu gering ist, scheint hochplausibel.

Und natürlich muss ein top nicht unbedingt was aussagen. Schließlich gibts ja auch die Möglichkeit Prozesse komplett unsichtbar zu machen. Stichwort lkm Rootklit.

hm... sehr viele apaches, aber keiner davon scheint wirklich viel zu tun zu haben...

cpu ist recht idle, es findet kein nennenswertes swapping statt.

so ins blaue rein wuerde ich auf zu wenig bandwidth tippen.

Und die aussagekräftigste Zeile hast beschnitten.
Wie schauts mit dem Load aus?

^ Forum Linux-Support #1765795
	Re: Hilfe! Der ram ist voll und ich weiss nicht wieso

mjy@geizhals.at

13.09.2004, 06:26:37

Also wenn du mich fragst:

- mehr RAM würde evtl. helfen, weil die DB größer als der "cached"-Wert ist (d.h. möglicherweise wird zuviel auf die Platte zugegriffen, probier mal vmstat 1 - in die bi/bo-Spalten schauen)

- natürlich kann auch das DB-Design bzw. die Programmierung schuld sein - ich kann hier leider keine spezifischen Tips geben, aber eine bessere MySQL-Konfiguration oder besseres Datenbank-Design bzw. -Indizierung kann viel mehr bringen als mehr RAM

Daß der RAM "voll" ist, ist jedenfalls kein Problem - sei froh, daß Linux damit etwas sinnvolles macht (Datenbank cachen).

Marinos J. Yannikos <mjy@geizhals.at>

EU-Recht im 21. Jhdt.: Bewährungsstrafen für Körperverletzung mit Todesfolge, Haftstrafen für Raubkopierer ...

@all

Linux ist für mich Fremdland.

Aber die Diskussion die hier geführt wird ist bemerkenswert.
Aus den Postings für mich erkennbar, einige wirkliche Fachleute am diskutieren.

So etwas entschädigt für einigen Schwachsinn der im Forum oft geschrieben wird, meine Hochachtung!

Liebe Grüsse aus Linz

FRED

ha

genau das ging mir auch durch den kopf =)

Ich denke wir haben die Fachleute jetzt geschockt.
Leider keine Weiterführung des Threds ...........

Liebe Grüsse aus Linz

VRED

*threads

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung