Tag: performance

Tuning d’un servidor MySQL

2009/07/13 7 comentaris

Reading time: 2 – 2 minutes

Aquesta última setmana he tingut alguns problemes de rendiment amb un servidor MySQL, de fet, hi havia en concret una taula que tenia fins a 53 milions de registres, malgrat el seu espai tampoc era tan gran al voltant de 4Gb l’accés de lectura i escriptura a la taula era molt lent, sobretot per funcions de filtrat una mica complexes.

Doncs bé, coses que he aprés que potser ús poden anar bé són:

Cal habilitar les ‘slow_query_logs’ i tenir indexats tots els camps que apareixen després dels WHERE’s, això millora considerablement el rendiment.
Cal incrementar el innodb_log_file_size fins a un 25% del valor del innodb_buffer_pool_size; això redueix considerablement el temps d’escriptura.
Usar JFS, com a sistema de fitxers del directori ‘data’ del MySQL. És substancialment més ràpid que el ext3. Exemples de rendiment.
Posar els logs en un disc dedicat, diferent del disc que té les dades.
Usar el paràmetre ‘noatime’ en la partició que conté les de dades del MySQL.
Deshabilitar la partició de SWAP, usar un ‘innodb buffer spool’ ben gran, sempre pensant amb la RAM disponible.
Montar els directori temporal de MySQL sobre una partició RAM.
Reduir el key_buffer size a 1-2Mb si no s’usen taules MyISAM.
Usar el kernel 2.6 amb SMP amb processador multi-cos, és especialment important per aplicaions multithread com el MySQL.
Usar RAID0 (stripped disks) i usar un servidor de replicació per les còpies de seguretat. Millora els temps d’I/O del disc, com és lògic.

Problemes de rendiment OpenFiler amb VMWare Server [solucionat]

2008/09/14 2 comentaris

Reading time: 3 – 4 minutes

Després de molts mesos amb un greu problema de rendiment al servidor SAN/NAS de casa que tinc montat en una màqina virtual d’VMWare Server sobre Ubuntu 8.04 LTS, per fi m’he decidit a arreglar el problema. En algún altre post havia comentat el problema, la qüestió és que el rendiment dels 1.5Tb que tinc al servidor des del sistema operatiu de Host és d’uns 70MB/s però les mateixes proves des dels discos gestionats per la màquina Guest, o sigui l’OpenFiler, donaven uns patetis 3, 4 o com a molt 5MB/s. O sigui, que quan s’accedia per NFS o SMB als recursos compartits el rendiment era insuficient i d’altres servidors o màquines que usen aquests recursos se’n veien repercutits.

Finalment després de buscar una mica vaig veure que el problema venia de les interrupcions del sistema que es perdien degut a que el clock rate del servidor Host no era capaç de processar tantes interrupcions. Així doncs, investigant sobre el tema vaig veure que el que cal fer és donar suport HPET, en el meu cas perquè això funcioni ho he hagut d’activar també a la BIOS del HP ML110 que uso com a servidor físic. Amb aquests canvis els tests de velocitat de la màquina virtual amb OpenFiler m’han millorat substancialment i ara mateix donen resultats al voltant de 50MB/s. Obviament, encara estic lluny d’un rendiment òptim però ja no sé si això és tema de configuració o si el problema és més profund i ja depèn de la propia gestió interna que fa l’VMWare amb els mòduls que fan d’interficies entre el hardware real i el virtual.

Si voleu saber si teniu el HPET activat o no al kernel és tan senzill com mirar al dmesg:

root@vm0:~# dmesg |grep hpe
[  120.210408] hpet clockevent registered
[  120.210412] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[  120.210416] hpet0: 3 64-bit timers, 14318180 Hz

En cas de no tenir-lo activat, cal que activeu el següent al fitxer .config del kernel:

CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_RTC=y

A part d’això hi ha d’altres opcions per tal d’acotar aquest tipus de problemes, algunes que permeten estabilitzar les màquines virtuals malgrat no les expremem al màxim ens poden permetre funcionar millor si el rendiment no és el màxim dels nostres problemes i no saturem el Host. Per exemple, es pot afegir al fitxer .vmx de la màquina virtual la següent opció:

host.useFastClock = FALSE

Per cert, si voleu identificar el problema el kernel de la màquina Host dona errors de l’estil:

Aug 21 12:56:11 dey kernel: rtc: lost some interrupts at 2048Hz.

o també coses així:

select() to /dev/rtc to wait for clock tick timed out.

Com sempre a google podeu trobar moltíssima informació de com ajustar el vostre Linux perquè rendeixi al màxim amb VMWare. Per la meva part, ara hem queda posar en marxa mil i una coses que depenien d’aquest servidor de fitxers que mica en mica anava obligant-me a parar serveis per manca de rendiment. Espero que properament ja pugui posar en marxa funcions com l’album de fotografies i d’altres similars.

openfiler: potent i complicat de configurar

2008/03/15 6 comentaris

Reading time: 4 – 6 minutes

M’ha costat deu i ajuda posar a funcionar l’openfiler al final ja era una qüestió d’honor. Després de provar amb la versió pre-instal·lada com appliance i amb dues versions instal·lades per mi no hi havia manera de que funcionés tot plegat com volia.

Problema reconeixer volums lògics pre-creats

El primer gran problema ha estat que jo ja tenia un volume group creat, amb dos logic volumes (unitats lògiques d’informació usades per LVM). Doncs bé malgrat el linux me’ls retornava sense problemes amb el vgdisplay i lvdisplay quan anava a l’interficie de l’openfiler no hi havia manera que apareguessin els volums lògics. El grup de volums si que sortia però els lògics no. Doncs bé la solució l’he trobat després de molt buscar pels forums a aquest thread: How to get volumes back after reinstallation without config backup.

La gràcia esta en un script que bàsicament genera un fitxer XML de configuració que usa l’openfiler per saber quins volums hi ha al sistema: /opt/openfiler/etc/volumes.xml. El fitxer és força simple i només té una llista de volums lògics relacionats a un grup de volums. L’script també afegeix al /etc/fstab les línies necessaries perquè aquests volums lògics es montin a l’arrancar el sistema.

Còpia de l’script que he trobat al forum: remake_vol_info.

Problema LDAP amb tots els serveis i especialment amb el SMB

Doncs bé, aprofitant que openfiler porta un servidor LDAP volia gestionar les comptes de tots els serveis a través d’un únic punt. Així doncs, el primer problema ha estat saber com activar el servidor que porta internament perquè la documentació no ho explica massa bé, ja que si anem a serveis i li fem un enable sense donar cap error no s’aixeca ni a la de tres. Aprofito per comentar que la interficie gràfica de l’openfiler és realment pèssima i difícil d’entendre. A més, l’experiència d’usuari esta molt poc cuidada perquè moltes coses donen errors i no ho explica retorna enlloc. Així doncs t’hs de buscar la vida monitoritzant els fitxers de logs del linux que té per darrera.

Llavors he intentat actualitzar el sistema a través de la funció d’update que porta la pròpia interficie. Doncs be, també fallava així doncs ho he provat des de la línia de comandes amb un simple:

conary updateall

La cosa fallava amb el mateix error:

...
Warning: Unhandled exception occured when invoking callback
/user/lib/pgthon2.4/site-packages/conary/streams.py:416
...

Després de googlejar una bona estona, la solució ha estat:

conary update conary --replace-files
conary updateall --replace-files

Amb això he aconseguit finalment fer update. Però el problema amb LDAP continuava igual. Al final he deduit que si posava la informació a accounts -> authentication. Amb el password que he posat al fer la instal·lació per l’usuari de configuració del web la part d’usuaris i grups semblava que s’activa i el LDAP server començava a funcionar tot solet.

Així doncs, he pogut accedir a la gestió de comptes i crear un grup d’usuaris i un usuari de proves. Doncs bé, després de suar tinta per entendre tot el tema de gestió de shares i de veure que no hi havia manera d’accedir als recursos compartits de forma autenticada, he decidit aprofitar la meva experiència en linux per veure com estava tot configurat.

La qüestió és que he vist que tan el SMB, com el FTP, HTTP/WebDav, etc. anaben contra PAM però aquest no tenia configurat cap enllaç cap a LDAP, per tant, per molt que estigués funcionant era impossible que mai autentiques cap usuari.

Llavors he executat el authconfig per configurar l’autenticació PAM contra LDAP, i l’he deixat així:

original size

Al marcar l’autenticació LDAP per SMB, no ús ho perdeu m’ha dit que faltava el paquet pam_smb, o sigui, el pàquet de PAM que té el handler capaç de gestionar la connexió contra LDAP pel samba. Algú em pot explicar com pretenien la gent d’openfiler autenticar samba amb LDAP si no hi havia això instal·lat? aquí ja he arribat a la conclusió que això de l’openfiler esta verdíssim.

Bé doncs, després de suar una mica amb tot això que comento ja funciona tot contra LDAP a la perfecció!!! realment he de reconeixer que sóc una persona obstinada,eh!? perquè n’hi ha per deixar-ho correr. Després de tot el que he explicat i les hores que he hagut d’invertir per descobrir-ho.

Rendiment OpenFiler virtual

2008/03/15 No hi ha comentaris

Reading time: 2 – 2 minutes

Porto tot el dia fent proves amb l’OpenFiler com a màquina virtual dins del servidor HP que estic montant. Doncs, bé apart dels detalls tècnics volia fer una simple i interessant prova que després de veure el resultat encara em té estorat. He fet un test de velocitat amb el hdparm per saber la velocitat de transferència entre l’ubuntu que fa de servidor d’VMWare i un disc dur de 750Gb:

root@vm0:~# hdparm -t /dev/sdc1
/dev/sdc1:
 Timing buffered disk reads:  314 MB in  3.02 seconds = 104.11 MB/sec

Després des de la màquina virtual amb OpenFiler (basat en linux Red Hat) he fet la màteixa prova:

[root@nas0 ~]# hdparm -t /dev/sdb1
/dev/sdb1:
 Timing buffered disk reads:   66 MB in  3.05 seconds =  21.65 MB/sec

Malgrat el nom del dispositiu surti diferent el dispositiu és el mateix, això passa perquè en la màquina virtual el dispositiu no és el tercer dispositiu ‘SATA‘, sinó el segon. La màquina virtual té capturat el dispositiu físic, així doncs trobo que la diferència de velocitat és exagerada. També s’ha de comentar que l’OpenFiler no m’ha deixat instal·lar-se en 64bits sobre VMWare i ho he hagut de fer amb 32bits, no sé pas si aquesta diferència tan brutal pot ser deguda a això.

Els recursos que tinc assignats a l’OpenFiler són:

Si algú té la possibilitat de fer alguna prova semblant, o l’ha fet que avisi. De totes formes, diria que amb màquines virtuals de 64bits no puc capturar el dispositiu real o això m’ha semblat llegir que deia el VMWare. Gran defecte sota el meu punt de vista.