MySQL 5.5 lage belastingl, maar veel writes

Pagina: 1
Acties:

Acties:
  • 0 Henk 'm!

  • Mr_Big
  • Registratie: Februari 2002
  • Niet online
Na het afstruinen van vele sites ben ik er nog nit uitgekomen: onze MySQL 5.5 server op Centos 6.3 x64 schrijft veel meer weg dan dat er wordt gelezen. Terwijl ik gezien het gebruikspatroon (m.n. het 'gebruiken' van de data in de applicate DB's, niet toevoegen van nieuwe data) juist andersom zou verwachten. Door deze constante 'druk' op de harde schijven vallen de prestaties mij wat tegen bij wat zwaarder gebruik.

Hieronder een weergave van een 'iostat -d 5 vda' op een rustig moment (maandagavond 22:30):
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda               3.20         0.00        27.20          0        136

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda              20.20         0.00       371.20          0       1856

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda               3.40         1.60        27.20          8        136

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda              17.60         0.00       684.80          0       3424

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
vda               2.40         0.00        19.20          0         96


de relevante configuratie in my.cnf ziet er als volgt uit:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
# i/o settings
innodb_io_capacity              = 400
innodb_read_io_threads          = 8
innodb_write_io_threads         = 8

# Cache settings
key_buffer_size                 = 1M
query_cache_type                = 0
query_cache_size                = 0M
query_cache_limit               = 0M
table_open_cache                = 3072
table_definition_cache          = 1536
thread_cache_size               = 32

# Per thread buffers
read_buffer_size                = 1M
read_rnd_buffer_size            = 2M
sort_buffer_size                = 1M
join_buffer_size                = 2M

# Temp tables
max_heap_table_size             = 192M
tmp_table_size                  = 192M

# InnoDB
innodb_buffer_pool_size         = 1900M
innodb_additional_mem_pool_size = 16M
innodb_log_file_size            = 128M
innodb_log_buffer_size          = 8M
innodb_flush_method             = O_DIRECT
transaction_isolation           = READ-COMMITTED
innodb_autoinc_lock_mode        = 1


Grofweg is de verhouding schrijven:lezen 3:1, terwijll ik eerder 1:5 verwacht.
Heeft iemand een idee hoe ik dit kan aanpakken, of nog beter, kan oplossen?

Acties:
  • 0 Henk 'm!

  • Juup
  • Registratie: Februari 2000
  • Niet online
Heel vaak "SHOW PROCESSLIST" in de mysql console doen?

Ben ik nou zo dom of zijn jullie nou zo slim?


Acties:
  • 0 Henk 'm!

  • Mr_Big
  • Registratie: Februari 2002
  • Niet online
Blijkt te gaan om een regelmatig terugkerend statement "REPLACE INTO ..."
Dit betreft een Zarafa database, dus aan de statements zelf is niets te doen en ik verwacht dat die ook wel zijn geoptimaliseerd.

Kan het zijn dat de hoge iowait komt omdat de db-server en applicatieserver niet op dezelfde hardware staan, maar zijn geschieden door een netwerk? Dit netwerk heeft een (ping) latency van 1,5 ms. Lijkt niet veel, maar kan toch zijn dat dat optelt bij meerdere queries. Ik kom daar na een groot aantal zoekopdrachten op internet niet echt achter.

Ook vraag ik mij af of "transaction_isolation = READ-COMMITTED" geschikt is voor een EXT4 filesystem. Ik lees daarover dat daardoor alle opdrachten sequentieel worden weggeschreven i.p.v. asynchroon. Ik ga die optie vanavond eens aanpassen.

[ Voor 18% gewijzigd door Mr_Big op 15-01-2013 11:50 ]


Acties:
  • 0 Henk 'm!

  • Juup
  • Registratie: Februari 2000
  • Niet online
ipv MySQL te optimaliseren kun je beter proberen om het antal (Zarafa) writes te verminderen.

Ping van 1.5ms is trouwens wel erg veel tussen 2 machines. Kan dat niet minder?

Ben ik nou zo dom of zijn jullie nou zo slim?


Acties:
  • 0 Henk 'm!

  • Mr_Big
  • Registratie: Februari 2002
  • Niet online
De machines staan dan ook enkele kilometers tientallen uit elkaar :-)
Ik ga de database dichterbij halen (scheelt 1 ms)

Zoals gezegd: de queries die Zarafa gebruikt zijn niet echt aan te passen. Het gebruik ook niet: je kan mensen moeilijk zeggen om bijvoorbeeld op alleen de even dagen mail te gebruiken en de andere helt op de oneven dagen.

Daarom zoek ik het ook in een optimalisatie van MySQL, omdat ik vermoed dat de machine op zich veel meer kan en ik mij verwonder over de hoeveelheid writes.

Acties:
  • 0 Henk 'm!

  • Juup
  • Registratie: Februari 2000
  • Niet online
Zit de Zarafa db in InnoDB of in MyISAM?
Ik meen me te herinneren dat InnoDB beter was bij veel writes.

Ben ik nou zo dom of zijn jullie nou zo slim?


Acties:
  • 0 Henk 'm!

  • Mr_Big
  • Registratie: Februari 2002
  • Niet online
InnoDB !
MyISAM wordt voor zover ik weet niet eens (meer) ondersteund, laat staan aanbevolen.
Pagina: 1