PDA

Bekijk Volledige Versie : server optimalisatie: SQL , Magento , /dev/shm



askmurphy
03/10/09, 21:45
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 !

:drool:

Randy
03/10/09, 21:49
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 (http://www.ispi.eu) 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
03/10/09, 23:54
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-is-devshm-and-its-practical-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 (http://www.ispi.eu) 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
04/10/09, 00:05
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
04/10/09, 01:07
'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
04/10/09, 06:58
Staat niet veel in:

---

[mysqld]
local-infile=0

---

TEACH ME PLEASE ;-)

t.bloo
04/10/09, 11:42
begin hier eens mee

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

Ber|Art
04/10/09, 12:29
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/comments/performance-is-key-notes-on-magentos-performance/ ;)

en deze: http://inchoo.net/ecommerce/magento/boost-the-speed-of-your-magento/

wonko
04/10/09, 13:30
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
04/10/09, 20:48
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
04/10/09, 20:49
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
04/10/09, 21:10
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
04/10/09, 21:16
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
04/10/09, 21:20
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
:huh:


4 en 128 wat? appels, peren, Megabytes!
@Randy: deze opties zijn een aantal en geen geheugen hoeveelheid, RTFM :D

Randy
04/10/09, 21:28
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?

askmurphy
04/10/09, 21:48
Veel beginners willen graag vragen stellen en stellen opbouwende antwoorden
zeer op prijs. Studie (boeken, internet) dragen zeker bij !

Als ik iemand op de één of andere manier (je weet dat maar nooit tenslotte) beledigd heb dan hierbij mijn excuses. Ben ook maar een beginner en als beginners hier geen vragen mogen stellen dan horen wij beginners dat graag.

Wie is Berry ?

Zal al die *.cnf bestanden eens bekijken, zou mooi zijn als je wat advies kon geven... Heb ook naar MEM CACHE en zo gekeken, ben er wel voorzichtig mee aangezien de server wel moet blijven draaien ;-D

Weet zeker dat er nog vele andere beginners zijn die dolgraag wat van de experts willen leren.. Alle info en hulp is welkom !

:rolleyes:

RichardVD
04/10/09, 22:01
Wie is Berry ?
Ber|art met de blauwe naam in dit topic.

askmurphy
04/10/09, 22:02
Heb even de file my-huge.cnf naar my.cnf gekopieerd, mysql herstart en
vervolgens mysqltuner weer eens geprobeert.

Dit is de output:

-----
[root@server01 etc]# cd /root
[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-log
[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: 12

-------- Performance Metrics -------------------------------------------------
[--] Up for: 50s (2K q [51.880 qps], 66 conn, TX: 1M, RX: 440K)
[--] Reads / Writes: 91% / 9%
[--] Total buffers: 442.0M global + 12.4M per thread (100 max threads)
[OK] Maximum possible memory usage: 1.6G (42% of installed RAM)
[OK] Slow queries: 0% (0/2K)
[OK] Highest usage of available connections: 4% (4/100)
[OK] Key buffer size / total MyISAM indexes: 384.0M/5.6M
[OK] Key buffer hit rate: 99.0% (10K cached / 109 reads)
[OK] Query cache efficiency: 57.4% (1K cached / 2K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 88 sorts)
[!!] Joins performed without indexes: 8
[OK] Temporary tables created on disk: 3% (3 on disk / 87 total)
[OK] Thread cache hit rate: 93% (4 created / 66 connections)
[OK] Table cache hit rate: 97% (209 open / 215 opened)
[OK] Open file limit used: 36% (418/1K)
[OK] Table locks acquired immediately: 100% (1K immediate / 1K locks)
[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
Variables to adjust:
join_buffer_size (> 128.0K, or always use indexes with joins)
----

Nu begrijp ik dat MYSQL dagen moet draaien om via dit programma de boel verder te kunnen optimaliseren, maar wellicht kan iemand nog wat tips geven ?

Ook verdere optimalisatie tips zijn welkom...

Alvast hartelijk bedankt !!!!

t.bloo
04/10/09, 22:07
ben er wel voorzichtig mee aangezien de server wel moet blijven draaien

aparte testserver gebruiken?

mikeh
04/10/09, 23:46
Meer bier zuipen op zondag!

Dit topic is echt euh, clueloos op z'n zachts gezegd.

Randy
05/10/09, 03:01
Start die mysqltuner nu niet iedere 3 minuut. Zolang er geen data is verzameld (en dat duurt enkele uren, afhankelijk van het aantal bezoekers*) Vergelijk eerst de my-huge eens met wat je had en trek conslusies. Daar leer je van. Tenminste, dat is de bedoeling.

Verder heb je nog niets aan deze melding gedaan: (Google is je vriend)
[!!] Total fragmented tables: 12

* Het aantal bezoekers kan ik je wel mee helpen. Post maar eens een URL dan doe ik een belletje naar de Ukraïne :lovewht: