[MYSQL]Swapt als een gek

[van.der.schulting]

Ik heb een tabel van ca. 8GIG groot. Als ik een kolom probeer te veranderen (ALTER TABLE STATEMENT), dan begint MySQL te swappen als een gek en duurt het eeuwen voor het statement is uitgevoerd. OK, supersnel zal het sowieso niet gaan, maar een andere client met een Ubuntu installatie is in 10 minuten klaar, terwijl deze server enkele uren staat te pompen. De client staat ook bij lange na niet zo heftig te swappen als de server, terwijl de swappiness instelling op beide machines wel gelijk is.
De client is wel iets sneller ivm een SSD disk, terwijl de server beschikt over SAS, maar dit is wel een heel groot verschil.

Als ik kijk naar de output van 'top' dan gebruikt MySQL 495MB. De databaseserver heeft in totaal 4GIG beschikbaar en draait op Debian 6.
Mijn boerenverstand zegt me dat dat het probleem niet zou moeten zijn, maar misschien begrijp ik het verkeerd.

Zie hier de output van top:

code:

top - 17:33:40 up 125 days, 21 min,  2 users,  load average: 4.12, 3.98, 3.60
Tasks: 140 total,   1 running, 139 sleeping,   0 stopped,   0 zombie
Cpu(s):  1.9%us,  0.7%sy,  0.0%ni, 54.1%id, 43.3%wa,  0.1%hi,  0.0%si,  0.0%st
Mem:   4063472k total,  3176216k used,   887256k free,      972k buffers
Swap:  4925424k total,    38248k used,  4887176k free,  2359664k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                          
 6761 mysql     20   0  777m 493m 3320 S   12 12.4  11588:18 mysqld                                                                                           
   17 root      20   0     0    0    0 S    0  0.0   0:41.62 events/2                                                                                         
13924 bart      20   0  107m  25m  580 S    0  0.6   8:59.59 ruby                                                                                             
    1 root      20   0  8356  328  260 S    0  0.0   1:39.12 init

Ik heb het volgende geprobeerd:
1. 'Spelen' met de swapiness (sysctl vm.swapiness) levert niets op.
2. Ik heb al geprobeerd de diskcache van de swapfile leeg te halen, maar die loopt dan meteen weer op. Zoals je in het plaatje ziet staat hij op 2,3GIG.
3. De swap uitschakelen werkt alleen maar averechts.

Niks werkt.
Ik heb het gevoel dat het echt iets super simpels is, maar heb geen idee waar ik het zoeken moet. Kan iemand me opweg helpen?

[Gomez12]

A: Check je mysql settings of die niet ergens vast staat op 512 Mb
B: SSD kan een giga-verschil maken als jouw machine naar dezelfde schijf staat te swappen en daardoor een gigantische queue krijgt.

[birdie25]

Je iowait is 43%, blijkbaar kunnen je disks het niet aan.

[--WaaZaa--]

Je zou met iostat nog eens wat specifieker kunnen kijken op de utilization van je disken, maar birdie25 zal gelijk hebben

[rippiedoos]

Mijn mening over MySQL blijkt nu ook weer waarheid te zijn: zodra je MySQL niet meer volledig in memory past wordt het zaakje onwerkbaar traag. Tijd om over te stappen op iets anders, bijvoorbeeld PostgreSQL als het mogelijk is. Dan kun je ook opeens meer dan 1 CPU benutten, wat handig kan zijn!!

En als dat niet kan, 16G in de machine zetten en die 8G-tabel past weer in het geheugen zonder dat de machine staat te swappen als een gek.

[Gomez12]

rippiedoos schreef op dinsdag 05 februari 2013 @ 14:47:
Mijn mening over MySQL blijkt nu ook weer waarheid te zijn: zodra je MySQL niet meer volledig in memory past wordt het zaakje onwerkbaar traag. Tijd om over te stappen op iets anders, bijvoorbeeld PostgreSQL als het mogelijk is. Dan kun je ook opeens meer dan 1 CPU benutten, wat handig kan zijn!!

Alhoewel ik ook graag rant op MySQL gaat een andere db-server je hier niet helpen.

Meerdere CPU's is enkel nuttig als je query's CPU-bound zijn, hier zijn ze simpelweg I/O bound.

Over stappen op PostgresSQL gaat zijn probleem niet oplossen, enkel maar meer problemen veroorzaken.

[van.der.schulting]

Probleem is opgelost. Ik had een id gewijzigd in een varchar, omdat dat in een bepaald geval handiger was. Vervolgens ging ik zoeken op de varchar in een tabel van 900.000 records... vreemd he dat MySQL dan traag wordt...

Snelste oplossing is de varchar even terugdraaien en er weer een int van maken...

Via het command SHOW PROCESSLIST in de MySQL console heb ik uitgevonden dat ik redelijk goed kan zien wat de server uitvreet, dus zo kom ik voorlopig een heel eind.

Thanks voor de hulp anyway

[rippiedoos]

Gomez12 schreef op dinsdag 05 februari 2013 @ 16:43:
[...]

Alhoewel ik ook graag rant op MySQL gaat een andere db-server je hier niet helpen.

Meerdere CPU's is enkel nuttig als je query's CPU-bound zijn, hier zijn ze simpelweg I/O bound.

Over stappen op PostgresSQL gaat zijn probleem niet oplossen, enkel maar meer problemen veroorzaken.

Eens.

En toch als ik elke keer weer dit soort verhalen hoor als die van de topic starter, dan denk ik toch altijd: waarom hebben mensen voor MySQL gekozen...

@TS: Mooi dat je probleem is opgelost!!