Zu wenig RAM oder was?

[badera]

Seit gestern stelle ich fest, dass plötzlich auf meinem Server mysql am Morgen jeweils nicht mehr läuft. Gestern habe ich einfach den Server neu gestartet; heute habe ich mal die Logs angeschaut, weil mysqld wieder nicht mehr lief.

Code: Alles auswählen

...
May 30 05:30:01 localhost /USR/SBIN/CRON[5824]: (root) CMD (bash /etc/backup/pibookdaily > /etc/backup/log-pibookdaily.log)
May 30 05:34:59 localhost kernel: oom-killer: gfp_mask=0xd0
May 30 05:35:00 localhost kernel: DMA per-cpu:
May 30 05:35:00 localhost kernel: cpu 0 hot: low 2, high 6, batch 1
May 30 05:35:00 localhost kernel: cpu 0 cold: low 0, high 2, batch 1
May 30 05:35:00 localhost kernel: Normal per-cpu:
May 30 05:35:00 localhost kernel: cpu 0 hot: low 12, high 36, batch 6
May 30 05:35:00 localhost kernel: cpu 0 cold: low 0, high 12, batch 6
May 30 05:35:00 localhost kernel: HighMem per-cpu: empty
May 30 05:35:00 localhost kernel: 
May 30 05:35:00 localhost kernel: Free pages:        1328kB (0kB HighMem)
May 30 05:35:00 localhost kernel: Active:14247 inactive:14098 dirty:0 writeback:0 unstable:0 free:332 slab:1910 mapped:28268 pagetables:297
May 30 05:35:00 localhost kernel: DMA free:712kB min:44kB low:88kB high:132kB active:6444kB inactive:6208kB present:16384kB
May 30 05:35:00 localhost kernel: protections[]: 22 178 178
May 30 05:35:00 localhost kernel: Normal free:616kB min:312kB low:624kB high:936kB active:50544kB inactive:50184kB present:114624kB
May 30 05:35:00 localhost kernel: protections[]: 0 156 156
May 30 05:35:00 localhost kernel: HighMem free:0kB min:128kB low:256kB high:384kB active:0kB inactive:0kB present:0kB
May 30 05:35:00 localhost kernel: protections[]: 0 0 0
May 30 05:35:00 localhost kernel: DMA: 0*4kB 3*8kB 1*16kB 1*32kB 0*64kB 1*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 712kB
May 30 05:35:00 localhost kernel: Normal: 0*4kB 1*8kB 0*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 0*1024kB 0*2048kB 0*4096kB = 616kB
May 30 05:35:00 localhost kernel: HighMem: empty
May 30 05:35:00 localhost kernel: Swap cache: add 110493, delete 110350, find 6257/7822, race 0+0
May 30 05:35:00 localhost kernel: Out of Memory: Killed process 2131 (mysqld).
...

Es wird um 05:30 noch ordentlich einen cronjob gestartet. Dieses skript macht ein Backup wichtiger Daten des Servers auf eine externe Festplatte. Dazu werden ca. 1.5GB Daten zusammengezippt und auf diese externe Festplatte kopiert. Bis anhin hat das auch wunderbar funktioniert. Solche Probleme sind neu für mich; das einzige was eigentlich auf dem Server geändert hat, sind die Menge der Daten; also die Daten, die in dem zuletzt noch aufgerufenen cronjob gezippt werden, haben etwas zugenommen.

Nun stelle ich aber fest, dass plötzlich oom-killer anspringt und mysqld abschiesst - siehe oben. Weiter untem im syslog wird dann nochmals mysqld und auch noch zip selbst abgeschossen und dann noch apache.
Hier der ganze syslog

Was ist da wohl da Problem? Habe ich ein unsauberes System? Oder ist das normal? Könnte man dann vielleicht die swap-partition vergrössern?
Übrigens ist nicht etwa der Festplattenplatz am Ende, so wie "df -h" zeigt:

Code: Alles auswählen

Filesystem            Size  Used Avail Use% Mounted on
/dev/hda1             7.4G  1.2G  5.9G  16% /
tmpfs                  63M     0   63M   0% /dev/shm
/dev/hdb1             114G   66G   43G  61% /home
192.168.10.5:/volume1/backup
                      367G  214G  149G  60% /mnt/backup

Kleine Nebenfrage: was soll eigentlich obige Zeile

Code: Alles auswählen

tmpfs                  63M     0   63M   0% /dev/shm 

bedeuten? - Das ist ja nicht die swap-Partition. Keine Ahnung, was das mit den 63M soll.

hda ist gemäss cfdisk so partitioniert:

Code: Alles auswählen

                                 cfdisk 2.12p

                              Disk Drive: /dev/hda
                        Size: 8455200768 bytes, 8455 MB
              Heads: 240   Sectors per Track: 63   Cylinders: 1092

    Name        Flags      Part Type  FS Type          [Label]        Size (MB)
 ------------------------------------------------------------------------------
    hda1        Boot        Primary   Linux ext3       [/]              8066.59
    hda5                    Logical   Linux swap / Solaris               387.08

Aber vielleicht such ich da ganz am falschen Ort. Kann mir jemand auf die Sprünge helfen?

Besten Dank!
- Adrian

[HELLinG3R]

Das tmpfs ist ein Filesystem, mit dem du daten direkt im Ram ablegen kannst.
Das ist also so eine art unheimlich-schnelle Festplatte.
Der Platz der reserviert wird, ist nur belegt, wenn daten drin stehen - das ist also nur eine art "obergrenze" um zu verhindern, dass dein Ram vollgeschrieben wird.

Setz doch mal ein "free -m" ab, das gibt dir Auskunft über deine Speicherverwaltung. Lass dich nicht von der Zeile "Mem:" verschrecken, wenn da wenig Speicher frei ist - Linux nutzt ungenutzten RAM als Festplattenpuffer und gibt das dynamisch frei. Wie viel von Programmen belegt ist erkennst du an der Zeile "-/+ buffers/cache:"

[badera]

Danke für Deine Erklärung.

"free -m" gibt das da aus:

Code: Alles auswählen

             total       used       free     shared    buffers     cached
Mem:           124        117          7          0         13         44
-/+ buffers/cache:         58         65
Swap:          369          0        369

Momentan läuft auch alles rund. Ich sollte also diese Ausgabe mal prüfen, wenn ich den Backup-Job starte, der mir schlussendlich die Serverdienste abschiesst.

[badera]

So, ich habe die Ursache gefunden:

Das Skript, das mit dem cronjob gestartet wird, packt mit zip einige Verzeichnisse aus /home zusammen. Da nun neuerdings in einem Unterordner ein symlink auf das eigene Homeverzeichnis erzeugt wurde (wegen wine), kam zip beim Suchen aller zu packenden Dateien in eine Endlosschlaufe... Daher der imense RAM-Verbrauch und schliesslich der Absturz.

Nun wird halt zip mit -y aufgerufen, dass den Symlinks nicht gefolgt wird -> Das Problem ist behoben.
- Adrian