Onderwerp: OpenSUSE steeds trager en uiteindelijk niet meer bereikbaar

Ik zit met een heel vervelend probleem. Ik heb een OpenSUSE 10.3 server. Daarop draait Apache2, MySQL5, Postfix, Bind, Cyrus IMAP, FTP, clamav, MailScanner, Webmin en SSH. Er zitten 2 hardschijven in, die softwarematig in RAID1 staan.

Webmin en SSH zijn alleen bereikbaar vanaf een aantal IP adressen dat is opgegeven in iptables. Vaak draait de server een hele tijd goed, maar soms gaat alles geleidelijk trager. En uiteindelijk werkt bijna niets meer. Alleen websies zijn dan nog heel traag opvraagbaar, maar inloggen op SSH of mail checken lukt dan niet meer. De enige oplossing is dan om de server een reset te geven.

In de logfiles kan ik helemaal niets geks ontdekken. Ook kan ik met phpsysinfo op het moment dat het fout gaat zien dat het geheugen niet vol is. Ook wordt de CPU nauwelijks gebruikt.

Het probleem is vandaag dusdanig groot (2x moeten resetten), dat ik echt niet meer weet waar ik moet gaan zoeken. Is er misschien iemand die nog een idee heeft waar ik op kan letten?

Bij voorbaat dank.

O ja, ook wel belangrijk erbij te vermelden: in Apache is het uploaden e.d. gelimiteerd, zo ook bij de FTP (maximaal een bestand van 2GB uploadbaar) en het aantal MySQL connecties is 100.

Ik heb de indruk dat de hardeshijf druk bezig is, maar weet dat niet zeker.

Dat zou geen probleem mogen zijn, hoe hoog is je load? Als je

Code:

ps -elf

doet, wat zie je dan? Extreem veel processen van iets of niet?

Ik ben bereid even voor je te kijken indien je wilt, of ik het 1-2-3 kan oplossen ligt aan je probleem maar ik kan het wellicht voor je constateren

Desmond

Bedankt voor het aanbod. Dat wil ik zeker niet afslaan. Ik zal nog eerst zelf nog verder zoeken, maar anders kom ik bij je terug .

In de bijlage staat wat ik met ps -elf krijg. Het is een hele lijst, maar er draait ook veel op. Ik zie er zo geen gekke dingen op.

Wellicht is een screenshot beter, hier is niet veel van te maken.

Ik zie dat het inderdaad als Unix formaat was opgeslagen. Deze moet wel leesbaar zijn in het Windows kladblok.

Check eens je disk space?
df -h

Als je root filesystem vol-loopt (omdat bijvoorbeeld /tmp ook op het root filesystem staat) dan kan je dit soort problemen krijgen. (Het systeem kan dan geen lock files meer schrijven en dan kan je niet meer inloggen....)

De schijf is ook niet echt vol:

Bestandssysteem Grtte Gebr Besch Geb% Aangekoppeld op
/dev/md2 9,9G 4,8G 4,7G 51% /
udev 1,8G 140K 1,8G 1% /dev
/dev/md3 128G 60G 62G 50% /backup
/dev/md1 99M 16M 79M 17% /boot
/dev/md4 155G 22G 126G 15% /home

Maar er zit wel wat schot in. Ik ben vandaag naar het datacenter gegaan. Heb er 2 GB geheugen bij geprikt. Niet dat dat een oplossing biedt. Maar wel heb ik 1 schijf eruit getrokken en toen ging alles opeens weer veel sneller. Vervolgens de schijf terug gedaan en nu wordt het weer gesynct met de andere schijf (RAID1). Maar nu is het toch weer wat trager.

Het is een softwarematige RAID. Of de schijf is niet meer helemaal lekker, of de software RAID begint het om een of andere reden te begeven. Heeft iemand daar ervaring mee?

Ik heb 1 harddisk vervangen door een nieuwe. Vooralsnog draait alles weer op normale snelheid. Mocht het toch weer mis gaan, dan zal ik dat hier weer even melden .

Oorspronkelijk geplaatst door pippen

Het is een softwarematige RAID. Of de schijf is niet meer helemaal lekker, of de software RAID begint het om een of andere reden te begeven. Heeft iemand daar ervaring mee?

Ja. Als er 1 drive "onderwater" gaat proberen defecte sectoren te herstellen dan gaat het hele array daar op wachten. Speciale RAID edition harde schijven die proberen domweg niet om die herstelacties te doen, waardoor ze gewoon snel uit het array vallen. Als je zo'n falende schijf hebt, dan kun je beter de reserve disk uit de kast halen.

Kun je de output van S.M.A.R.T. posten? Een juist commando kan zijn

Code:

smartctl -a /dev/sda -d ata