server optimalisatie: SQL , Magento , /dev/shm

[askmurphy]

Wie weet hoe je een Linux server kan optimaliseren voor Magento en andere zware applicaties ?

Heb hier en daar wat gezien over /dev/shm : shared (ramdisk) geheugen.
Het schijnt dat je daarmee je systeem aardig kunt oppeppen..
Men maakt daarbij gebruik van een deel van het interne geheugen.

Wie heeft hier ervaring mee ?
Hoe moet je dat instellen ?
Kun je er ook extern geheugen voor gebruiken: een grote USB 2.0 memorystick of een SSD-schijfje er speciaal bij zetten ?
Hoeveel geheugen heb je nodig om een aantal magento-shops (10 - 50) snel
te kunnen laten draaien ?

Heb al heel wat magento-shops hier en daar gezien, 99% is vreselijk traag...

Andere optimalisatie tips zijn ook welkom !

[Randy]

Niet rommelen met de ramdisk. De winst die je hieruit haalt is minimaal. Tenzij je erg trage disken gebruikt. Een USB stick gaat je zeker weten niet helpen. Ga je schamen, we praten over een server.
Compiler aangezet, memory_limit hoog genoeg, MySQL optimalisatie toegepast, al door de .htacces heen gelopen?
Mijn speelsite is een beetje de snelheid zoals het zou moeten. Heel iets trager kan nog, maar je ziet inderdaad wel eens websites die niet echt vooruit te branden zijn. Laadtijden langer dan 2,4 seconden zijn vervelend, langer dan 3 seconden onaanvaardbaar.
Welke disks gebruik je in je server?"

[askmurphy]

Moet nog een hoop leren hoor ;-)

Heb een gewone DELL R200 server, zit momenteel 4GB (800Mhz), binnenkort komt er 4GB bij (is gelijk het maximum). Verder 2x 1TB SATA 7200rpm hd's.
Budget laat geen beter spul toe momenteel ;-)

Zou graag meer willen weten hoe je het een en ander nog kan verbeteren.

Vond hier info over de ramdisk: http://www.cyberciti.biz/tips/what-i...cal-usage.html

Kun je eens vertellen wat er al zoal moet gebeuren om het maximale uit dit systeem (en welk ander systeem dan ook) te halen en ook vooral het 'hoe' ?

'Compiler aangezet, memory_limit hoog genoeg, MySQL optimalisatie toegepast, al door de .htacces heen gelopen' ???? Nee, hoe moet dat ?

Niet rommelen met de ramdisk. De winst die je hieruit haalt is minimaal. Tenzij je erg trage disken gebruikt. Een USB stick gaat je zeker weten niet helpen. Ga je schamen, we praten over een server.
Compiler aangezet, memory_limit hoog genoeg, MySQL optimalisatie toegepast, al door de .htacces heen gelopen?
Mijn speelsite is een beetje de snelheid zoals het zou moeten. Heel iets trager kan nog, maar je ziet inderdaad wel eens websites die niet echt vooruit te branden zijn. Laadtijden langer dan 2,4 seconden zijn vervelend, langer dan 3 seconden onaanvaardbaar.
Welke disks gebruik je in je server?"

Magento is zeker een mooi systeem, snap alleen niet waarom het zo vreselijk traag is: lijkt mij een core-probleem..

[t.bloo]

wat die Magento allemaal per hit uit de database wil peuteren... joost mag het weten maar het is in ieder geval erg veel.

veel geheugen en database op een andere server is een van de makkelijkere dingen. Wel tegen MySQL vertellen dat 'ie dat geheugen mag gebruiken natuurlijk

[Randy]

'Compiler aangezet, memory_limit hoog genoeg, MySQL optimalisatie toegepast, al door de .htacces heen gelopen' ???? Nee, hoe moet dat ?

Ik kan je alles op een dienblad aanreiken, maar dan leer je er niets van. Post om te beginnen eens een output van je /etc/my.conf.

[askmurphy]

Staat niet veel in:

---

[mysqld]
local-infile=0

---

TEACH ME PLEASE ;-)

[t.bloo]

begin hier eens mee

http://lmgtfy.com/?q=mysqltuner

[Ber|Art]

MySQL tuner, PHP eAccelerator, MEM Cache, Apache optimize (en de mogelijkheden die Magento al bied). Dit draait allemaal stabiel met RedHat of CentOS en onze Magentoshops draaien snel en stabiel door deze optimalisaties op shared en dedicated servers.

en lees dit even door: http://www.magentocommerce.com/blog/...s-performance/

en deze: http://inchoo.net/ecommerce/magento/...-your-magento/

[wonko]

of huur iemand in die het wel kan, en je uitleg kan geven over wat hij doet, en vooral, waarom hij het doet. Verder kan ik je zeggen dat IO het traagst is, en caching de oplossing ervoor is.

[askmurphy]

Heb mysqltuner geinstalleerd en heb na een paar keer aanpassen van my.cnf / starten van mysqltuner / en herstarten van mysql nu dit in my.cnf :

[mysqld]
query_cache_size = 8M
join_buffer_size = 8M
thread_cache_size = 4
query_cache_limit = 512M
table_cache = 128



En dit krijg ik als resultaat:


[root@server01 ~]# ./mysqltuner.pl

>> MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering
Please enter your MySQL administrative login: da_admin
Please enter your MySQL administrative password:

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.51a-community
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: +Archive -BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 9M (Tables: 1772)
[--] Data in InnoDB tables: 4M (Tables: 225)
[!!] Total fragmented tables: 10

-------- Performance Metrics -------------------------------------------------
[--] Up for: 19s (534 q [28.105 qps], 14 conn, TX: 203K, RX: 89K)
[--] Reads / Writes: 95% / 5%
[--] Total buffers: 42.0M global + 10.6M per thread (100 max threads)
[OK] Maximum possible memory usage: 1.1G (27% of installed RAM)
[OK] Slow queries: 0% (0/534)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/5.6M
[OK] Key buffer hit rate: 98.4% (5K cached / 86 reads)
[!!] Query cache efficiency: 9.5% (47 cached / 493 selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 26 sorts)
[!!] Joins performed without indexes: 2
[OK] Temporary tables created on disk: 0% (0 on disk / 22 total)
[OK] Thread cache hit rate: 85% (2 created / 14 connections)
[OK] Table cache hit rate: 91% (64 open / 70 opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (683 immediate / 683 locks)
[!!] Connections aborted: 7%
[OK] InnoDB data size / buffer pool: 4.4M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Your applications are not closing MySQL connections properly
Variables to adjust:
query_cache_limit (> 512M, or use smaller result sets)
join_buffer_size (> 8.0M, or always use indexes with joins)


+++++++++++++++++++++++++++++++++

Wie kan mij hier verder mee helpen ?
Heb al diverse keren waardes aangepast in my.cnf , daarna mysql herstart
(/etc/init.d/mysqld restart) en mysqltuner weer gedraait. Steeds weer andere meldingen....

[Randy]

Als je niet weet wat je doet, verdiep je dan eerst in MySQL, of laat het doen door iemand die wel weet wat die doet. Nu kan ik hier een complete my.cnf neerposten voor je die redelijk goed is, maar hiermee help ik je niet, omdat je het nog niet zult snappen.
Begin eens met de zaken waar een [!!] voor staat. Zaken als "[!!] Total fragmented tables: 10" zouden je toch *iets* moeten zeggen?!

En kijk deze eens na:
thread_cache_size = 4
table_cache = 128

4 en 128 wat? appels, peren, Megabytes!

Verder heeft het _geen_ zin om MySQLTuner te runnen op een net opgestarte database, omdat er dan nog geen statistieken zijn. De "query_cache_size" mag omhoog. Houdt 32M aan voor elke Gbyte werkgeheugen. Je "thread_cache_size" mag bij 2Gbyte werkgeheugen best op 64G. Ik mis een hele innoDB sectie, etc. etc.

[askmurphy]

Beste Randy,

Zoals velen hier wil ik graag wat leren, het uit besteden is niet de bedoeling.

Uiteraard heb ik alle databases op mijn servertje geoptimaliseerd via directadmin.
Waarom mysqltuner nu nog steeds die fout geeft weet ik niet.

Je kunt mensen ook wat leren door ze bijvoorbeeld in dit geval een goede my.cnf bestand te tonen en vervolgens een uitleg van elke regel te geven.

Met 'Read the fucking manual tips' help je niet echt...

Server optimalisatie zou hier eigenlijk een vast topic moeten zijn !

;-) Murphy

Als je niet weet wat je doet, verdiep je dan eerst in MySQL, of laat het doen door iemand die wel weet wat die doet. Nu kan ik hier een complete my.cnf neerposten voor je die redelijk goed is, maar hiermee help ik je niet, omdat je het nog niet zult snappen.
Begin eens met de zaken waar een [!!] voor staat. Zaken als "[!!] Total fragmented tables: 10" zouden je toch *iets* moeten zeggen?!

[Randy]

Ik houd me dagelijks met server optimalisatie bezig. Veel leren, boeken, examens, en nog meer praktijk. RTFM hoort daar dus zeker bij. DirectAdmin is enkel om het VOOR KLANTEN van een provider makkelijker te maken om zaken te beheren. Het heeft he-le-maal niets met serverbeheer te maken. De lege my.cnf is hier een goed voorbeeld van.

<sarcasme>Ik zie dat je hoster bent, dus zal je aardig wat linux kennis hebben.</sarcasme> Dan weet je vast wel, uit welke directory je een voorbeeldconfuguratie kunt halen. Er staan er zelfs meerdere, dus zoek de juiste die het beste bij jouw situatie pakt en kopieer die inhoud (iets met cat en een >) naar je huidige my.cnf en restart MySQL dan. Het staat er netjes geSHAREd. Leuke voor de zondagavond.

(Ga ik lekker met het meisje naar de bios. Morgen wachten er weer 1900 servers op me bij $klant).

[t.bloo]

Ik voel met Randy mee, heb dezelfde idee bij jouw "vertel me wat ik moet doen" houding.

MySQL started within last 24 hours - recommendations may be inaccurate

had je een idee kunnen geven...

Verder zijn het geen foutmeldingen, maar aanwijzigingen.
En Magento gebruikt InnoDB dus dat moet er echt wel bij!

geoptimaliseerd via directadmin

4 en 128 wat? appels, peren, Megabytes!

@Randy: deze opties zijn een aantal en geen geheugen hoeveelheid, RTFM

[Randy]

Vooruit, een beetje dan: /usr/share/mysql/*.cnf. Om mijn 6000e posts te vieren vandaag. En dierendag natuurlijk. (kipswarma?)
MySQL is echter maar 15-20% van de optimalisatie van een single server. Al wat gedaan met de suggesties van Berrie?