Mysql på egen server eller apache-trimmning
 

Har en VM-server hos Citynetwork (City Cloud) som i sig fungerar bra.

Har dock lite trimmings-frågor.

När är det läge att sätta MySQL databasen på egen server?
Jag ser idag att det ibland går segt och antal queries som tar lång tid är ganska många. i "Top" ser jag att mysqld processen förbrukar en del, men svårt att avgöra om man skall trimma vidare i appache-configen och/eller my.cnf i Mysql.

Vad är fördelarna med att sätta sql-servern på egen maskin?
Eller bör jag satsa på Ngix eller httpdlight (eller vad den heter).

Vid 30 inloggade går det väldigt bra men så fort antal inloggade närmar sig 35 blir det segt. Eftersom det ofta är runt 40-50 inloggade vissa kvällar blir det ohållbart att fortsätta.

Har försökt gå över från MPM-prefork till MPM-worker men inte lyckats än, vid MPM-worker levererar den inga webbsidor trots att webservern är igång. Visst något som är felinställt, men har inte fått grep på vad än.

Kör med följande inställningar.

--------------------------------------------------------
Apache-config

Timeout 120
KeepAlive ON
MaxKeepAliveRequests 1000
KeepAliveTimeout 5

<IfModule mpm_prefork_module>
StartServers 12
MinSpareServers 10
MaxSpareServers 20
MaxClients 256
MaxRequestsPerChild 0
</IfModule>

-----------------------------------------------------------
MySql my.cnf

# * Fine Tuning
#
key_buffer = 256M
key_buffer_size = 512M
max_allowed_packet = 32M
thread_stack = 128K
thread_cache_size = 128

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover = BACKUP

max_connections = 128
table_cache = 1024
thread_concurrency = 4
#

# Max heap size etc
max_heap_table_size = 1G
tmp_table_size = 512M


# * Query Cache Configuration
#
query_cache_type = 1
query_cache_limit = 16M
query_cache_size = 16M
join_buffer_size = 4M

-------------------------------------------------------------------------
Så här ser (en del av) top ut och antalet appache2 överstiger 50 processer.
Minnet är fullt 4Gb av 4Gb möjliga och loaden ligger högt (tyvärr kopierade jag inte det)

25897 mysql 20 0 1201m 301m 2496 S 26 7.6 236:54.86 mysqld
142 root 15 -5 0 0 0 R 14 0.0 0:18.64 kswapd0
14301 root 20 0 123m 2920 1296 S 8 0.1 239:59.88 StoreGrid
4760 www-data 20 0 286m 51m 19m R 6 1.3 0:03.96 apache2
4560 www-data 20 0 291m 72m 19m R 6 1.8 0:03.90 apache2
4710 www-data 20 0 268m 46m 19m D 6 1.2 0:03.48 apache2
4748 www-data 20 0 276m 53m 18m R 6 1.3 0:02.42 apache2
5655 www-data 20 0 243m 9200 2892 R 6 0.2 0:00.96 apache2
5660 www-data 20 0 253m 32m 17m R 6 0.8 0:01.88 apache2
................ fortsättning 50 apache2 pids.
-------------------------------------------------------------------------

Kör Debian 64bit
2 Cpu, 4Gbyte Ram
Apche2, php5 (med eaccelerator) och mysql server
Det borde väl räcka ganska långt.

T ex hur an jag se om jag utnyttja båda processorerna?
Kan man se det på något sätt? Är det någon inställning för att utnyttja båda eller sker det automatiskt?


Några tips för att få lite rulle på detta även vid belastning.

mvh
Azone

Vad kör du för mjukvara på maskinen som använder MySQL?
Är det något du gjort själv? Hur är kvalitén på koden?

Slå på slow-query loggen och se vad som är långsamt.
Att gå dela webb och mysql bör gå snabbare, men kan också gå långsammare om man har dåliga frågor (som skickar mycket data över nätet).

Om det bara är CPU du behöver köp mer processor cores.
Hur det med diskprestandan?

Vad säger:

dd if=/dev/zero of=/root/test bs=1M count=1000

Edit: Är det bara 7.6% använt av MySQL?
Hur mycket "load" har du totalt?

Det är inte så att Apache inte släpper in fler användare?
Slå på mod_status och kolla.

Testen säger detta: Är det bra eller dåligt?

dd if=/dev/zero of=/root/test bs=1M count=1000

1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 69.9753 s, 15.0 MB/s


---------------------------------------------------------------------------
mod_status

apache2ctl status
Apache Server Status for www.exempel.se


Server Version: Apache/2.2.9 (Debian) PHP/5.2.6-1+lenny9 with
Suhosin-Patch mod_python/3.3.1 Python/2.5.2 mod_perl/2.0.4
Perl/v5.10.0

Server Built: Apr 20 2010 15:40:17
__________________________________________________ ________________

Current Time: Tuesday, 05-Oct-2010 21:55:46 CEST
Restart Time: Tuesday, 05-Oct-2010 21:53:07 CEST
Parent Server Generation: 0
Server uptime: 2 minutes 38 seconds
Total accesses: 549 - Total Traffic: 6.2 MB
CPU Usage: u33.68 s4.36 cu0 cs0 - 24.1% CPU load
3.47 requests/sec - 40.1 kB/second - 11.5 kB/request
2 requests currently being processed, 20 idle workers

__W________C____.____.._.._....................... ..............
.................................................. ..............
.................................................. ..............
.................................................. ..............

Scoreboard Key:
"_" Waiting for Connection, "S" Starting up, "R" Reading Request,
"W" Sending Reply, "K" Keepalive (read), "D" DNS Lookup,
"C" Closing connection, "L" Logging, "G" Gracefully finishing,
"I" Idle cleanup of worker, "." Open slot with no current process

---------------------------------------------------------------------------
top - 21:58:31 up 4:55, 2 users, load average: 0.78, 0.93, 1.52
Tasks: 105 total, 2 running, 97 sleeping, 5 stopped, 1 zombie
Cpu(s): 11.3%us, 4.3%sy, 0.0%ni, 83.9%id, 0.3%wa, 0.2%hi, 0.0%si, 0.0%st
Mem: 4065464k total, 3580680k used, 484784k free, 153804k buffers
Swap: 891568k total, 604k used, 890964k free, 2411404k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10333 mysql 20 0 815m 187m 5684 S 18 4.7 9:25.90 mysqld
11690 www-data 20 0 274m 57m 19m R 11 1.4 0:00.32 apache2
11653 www-data 20 0 0 0 0 Z 1 0.0 0:00.02 apache2 <defunct>
1 root 20 0 10316 748 620 S 0 0.0 0:01.94 init
2 root 15 -5 0 0 0 S 0 0.0 0:00.20 kthreadd
3 root RT -5 0 0 0 S 0 0.0 0:02.90 migration/0
4 root 15 -5 0 0 0 S 0 0.0 0:00.24 ksoftirqd/0
5 root RT -5 0 0 0 S 0 0.0 0:00.24 watchdog/0
6 root RT -5 0 0 0 S 0 0.0 0:03.52 migration/1
7 root 15 -5 0 0 0 S 0 0.0 0:00.50 ksoftirqd/1
8 root RT -5 0 0 0 S 0 0.0 0:00.02 watchdog/1
9 root 15 -5 0 0 0 S 0 0.0 0:02.60 events/0
10 root 15 -5 0 0 0 S 0 0.0 0:03.16 events/1
11 root 15 -5 0 0 0 S 0 0.0 0:00.88 khelper
46 root 15 -5 0 0 0 S 0 0.0 0:03.02 kblockd/0
47 root 15 -5 0 0 0 S 0 0.0 0:02.70 kblockd/1
49 root 15 -5 0 0 0 S 0 0.0 0:00.00 kacpid
50 root 15 -5 0 0 0 S 0 0.0 0:00.00 kacpi_notify
90 root 15 -5 0 0 0 S 0 0.0 0:00.00 ksuspend_usbd
96 root 15 -5 0 0 0 S 0 0.0 0:00.00 khubd
99 root 15 -5 0 0 0 S 0 0.0 0:00.00 kseriod
142 root 15 -5 0 0 0 S 0 0.0 0:00.10 kswapd0
143 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/0
144 root 15 -5 0 0 0 S 0 0.0 0:00.00 aio/1
650 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/0
651 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata/1
652 root 15 -5 0 0 0 S 0 0.0 0:00.00 ata_aux
Just nu inte så farlig last iofs
----------------------------------------------------------------------------------

vad säger dessa tester? Är det bra eller dåligt?

Du har hopplöst dålig diskprestanda. Dock så har du inte hög belastning på din server. Så den dåliga diskprestandan borde inte spela någon roll.
Min gissning är du har något lås någonstans... Ex att du anropar externa källor som inte svarar tillräckligt fort.

Skrivprestanda på en av våra servrar:
# dd if=/dev/zero of=/root/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 1.16141 seconds, 903 MB/s

vad har ni för diskar på er server om den pushar 1 gig/sec..

Vad är externa källor? Vad menas med det? Menar du t ex reklambanners på sidan som är långsamma eller liknande?

Eller något på servern som anropar något? Va skulle det kunna vara tex ?

Ex att ni kör curl-anrop eller liknande.

Rent spontant känns ju inte 35 användare som särskilt mycket. Låter som det bör vara läge att gå igenom koden. Är det databasfrågorna som tar tid?

På en virtuell Debian i prod (fixed size disk i VMware ESX mot SAN-disk) så får jag 153 MB/s och i test (thin provisioning disk i VMware server på lokal disk) så får jag 9,2 MB/s. Det får mig att tro att din leverantör kör med thin provisioning eller liknande vilket i kombination med en normalt belastad host reducerar diskprestanda till den nivån.

Låter inte så orimligt. Jag kommer upp i 588 MB/s på en 4-diskars RAID6 med 2.5" SAS-diskar.

Det var visserligen ett obelastat system. Men det är 15K SAS-diskar i RAID10 med många spindlar och mycket cache.

CityNetwork har problem med sitt lagringsbackbone, vi har samma problem på våra maskiner, enligt dem själva så ska det lösas under hösten.

Som jämförelse så får jag det här resultatet på en av våra maskiner som ligger hos CityNetwork:
dd if=/dev/zero of=/root/test bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 38.7964 s, 27.0 MB/s

Använder du index korrekt i MySQL ?
Vad säger slow-query.log ?

Vad loggas på maskinen och vad loggas inte?

Hur använder du PHP i Apache? mod_php eller fastcgi ?

Ja, jag fick något liknande när jag testade igen. Hoppas det fixar sig under "hösten" då, för snart är det vinter. Tack för info.

Vet ej om jag använder index korrekt. Kör Drupal CMS och jag påverkar därmed inte quieriserna manuellt.

Har stängt av loggarna eftersom det slöar ner en del, men har en del "slow-quieries" dock.

Jag kör mod-php. Försökte gå över till fastcgi och mpm-worker men fick det inte att fungera. Funderar på att byta till Nginx för att se om det hjälper något. Segheten kommer efter ett visst antal över 35 är inloggade. De är väldigt aktiva på forumet och använder det nästan som en "chatt". Men vi växer snabbt och behöver lösa detta snarast.

Kör med .htaccess eftersom det är standard i drupal och .htaccess finns i några mappar.

Testa att öka max_connections från 128 till typ 500 i my.cnf

Kör en SHOW PROCESSLIST; på mysql när det segar. Har du många anslutningar? Ligger många med state locked? Går de upp till max_connections? Thread cache hitrate?

Titta på cpu-stat under top. Har du mycket iowait på CPU-användandet?

Är det myisam-tabeller? Ok hit-rate på key buffern? Stiger slow_queries snabbt under högsta belastningen (show status like 'slow_queries')? Är det samma queries? Hur ser explain ut på dom?

Är query cache på? Hit rate? Är den för låg bör man antingen stänga av det eller åtgärda ration.

Jo det hoppas jag med, bästa är väl att kolla med CityNetwork när de är planerat till att bli fixat.

http://www.mysqltuner.com/ kan vara värt att kolla för att hitta enklare problem med mysql.

Tack! Väldigt bra frågor och svar. Skall titta på dessa parametrar vid nästa belastningstopp. Men följande vet jag redan nu.

• Det är Myisam tabeller (endast)
• Slow Queries stiger vid hög belastning eller om de bara bli vanligare pga fler queries ??
• Query cache är på (=1) och undrar om den motarbetar en del annan caching kring php (eaccelerator mm), läste något om det men vet ej. Det är kanske det du menar med att stänga av den om "hit rate" är för låg.
• Får många "locked" i mtop ibland vid hög belastning (= fler än 35-40 inloggade på sidan).
• Max-connections räcker nu sen jag fick lite koll på global vs thread buffer (minne). Se nedan. Har top 50 connections av 100 möjliga nu, men förväntar tillväxt.
• Jag kör både "MySqltuner.pl" och "Tuninng mysql ...?" Den förstnämnda ger flest ledtrådar till mig iaf. Men den säger konstant att Query cash size och limit bör ökas (men förstår inte varför och rädd att spräcka minesgränser samt att den aldrig verkar få nog).
• Har kört Optimize på samtliga tabeller.
• Kör Drupal 6 och den sägs ju vara ganska databasintensiv och förbättringar förväntas i Drupal 7, men det är ingen monstersida eller monstertrafik, så det borde gå att lösa med befintlig kapacitet tycker jag.

-----------------------------------------------------------------------------

Jag har hittat några allvarliga fel i mysqlkonfugurationen. T ex har/hade jag dålig koll på.

Mysql allokerat minne = globalbuffers + (max_connections + threaded buffers).

global_buffers:
key_buffer
net_buffer
(vilka fler?)

Jämfört med:

thread_buffers:
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer

Detta gav minnesproblem (allokerade mer än jag fysikt hade).
Nu går det stabilare ur den aspekten men det segar fortfarande ner sig vid många inloggade. Känns bättre med stabilt och segt än att det slår i taket och "totalkraschar".

Har många "locked" i mtop vid vissa situationer. Skall kolla Process list vid nästa belastningstop vid lunch eller kväll, när toppar brukar ske.


--------------------------------------------------------------------

Jag har bestämt mig för att installera om "ALLT" (LAMP eller alternativ). Inte bara beroende på mysql-problem utan för att få en mer korrekt struktur på hela paketet.

Funderar då på att gå över Nginx, eller Apache2 MPM-worker med Fastcgi samt sätta upp en kontrollpanel för att enklare hantera flera domännamn i framtiden.

Funderar på bl a"The perfect server"
http://www.howtoforge.org/perfect-se...nny-ispconfig3
Eller Liknande med Nginx.


mvh
Azone

Ja, nått måste vara fel om det börjar sega redan vid 40 inloggade samtidigt (såvida inte alla skulle sitta och uploada stora bilder samtidigt). Din diskprestanda verkar som sagt vara extremt låg.

På denna dedikerade server:
kör vi:
-Webshop
-VB-forum (45k medlemmar)
-Wordpress som CMS

Den klarar runt 1000 inloggade samtidigt innan det börjar bli lite segt.

Ja, kan inte annat än hålla med verkar som om diskprestanda kanske är den stora boven här. Visst kanske några samtidigt sitter och laddar upp bilder, men det sker nog mer sällan än det idag segar ihop sig. Tack för bra referens-siffror.

Nej, de motarbetar inte varandra. Eaccelerator är cachar opcodes för exekveringen av PHP, Qcache arbetar helt på databasnivå. Detta förutsatt att eaccelerator inte används med någon manuell variabel-cache (vet inte ens om det stöds av eaccelerator, men möjligt då det finns i t ex APC).

Ovanstående punkter tillsammans får mig att misstänka att problemet är tabell-låsningar vid skrivning. Myisam låser hela tabellen vid skrivning till en rad medan t ex InnoDB endast låser aktuell(a) rad(er). Att försöka kombinera InnoDB med MyISAM på en server kan dock ha sina problem, framförallt för att minnesanvändningen inte kan kombineras bra med de två då InnoDB slukar mest buffer pool. Alternativet är att gå igenom och åtgärda de frågor som låser upp tabellerna. Förmodligen, utan speciell stor insikt i varken drupal eller din sajt, är det något i stil med en view-counter för trådar/sidor/? som skriver direkt till rätt tabell och blockerar övriga queries. Dessa skrivs isåfall enkelt om till att läggas in i batches och skrivas till en separat tabell dessförinnan. Bättre diskprestanda skulle förvisso också avhjälpa om problemet är detta, men det skulle snarare skjuta upp än lösa det.

Ja, jag har svårt att påverka queries i drupal (åtminstone med min kunskap), visserligen skulle ja kunna ta bort någon funktion på sidan, men jag tycker ändå som andra varit inne på att 40 användare borde vara rätt få i sammanhanget och dessa eventuella låsningar pga MyISAM borde väl handla om millisekunder istället för halvminuters låsningar. Till dessa 40 får man iofs lägga till de anonyma som brukar var i häraden 20 men de har ingen aktiv del i forumet. Däremot uppdateras väl iofs view-counters och en del annat. Men 60 användare totalt borde väl systemet klara även om det inte är superoptimerat. I mysqltuner är läsningar ca 98% och skrivningar 2% om det nu säger något mera i sammanhanget?

Skall avaktivera view-countern och se om det gör någon skillnad iofs.

Tack för svar.

15mb/sec är inte "extremt dålig diskprestanda".
det är dock inte super.. men ganska basic prestanda på en mindre/äldre sata disk ;).
Speciellt på VPS som ofta har lite omvägar för arbetet och möjligen lite belastning hos andra vpser på värdmaskinen.

Om 15mb/sec är ett problem så kräver det en ganska krävande/stor site.
Har haft väldigt stora forum på hårdvara som snurrar på runt 19mb/sec.
Och det handlar om både stora och många db queries.

Så glöm flaskhalsen om diskprestanda just nu.
Det är något annat som agerar flaskhals :).

p.s 1gigabyte/sec prestanda är från minne till minne.. inte ren disk i/o ;).

Är lite trött nu när jag skriver... så ber om ursäkt om vissa saker är otydliga.

Den disken undrar jag också vad det är för något om det inte är något riktigt SAN på fibrechannel och stora raid grupper som ger hög IOPs.
Det andra jag tror på är att det blir hög minnes lokalitet och cachen funkar bra när man bara skriver nollor i följd.
Att köra if-källa från /dev/zero ger ingen reel mätning av diskar eftersom en intellegent kontroller kommer kunna allokera nollor utan problem.
Man bör istället köra /dev/urandom eller en förgenererad fil (om man inte vill dra massa CPU för att generera /dev/urandom).

Nu ska jag avslöja en stor eller liten hemlighet beroende på hur man ser på det.
VPS:er ligger på delat medium. Oftast så delas IOPs och MB/s skrivhastighet mellan många virtuella maskiner för att göra kostnadsbesparingar i infrastruktur - för att kunna ge så låga priser på VPS som möjligt. Tyvärr tittar de flesta kunder på priset framför reel prestanda. Har du en granne som drar mycket IOPs och MB/s så lär du inte få ut mycket prestanda.
Visst går det att dedikera resurser till de virtuella kunderna också. Det är en kostnadsfråga.
Min gissning är att trådskaparens leverantör har sina virtuella maskiner på glusterfs som är rekommenderad setup för den kontrollpanel de kör, detta är inte det snabbaste meta-lagringsfilsystemet och har en del begränsningar som medför försämrad prestanda. Det ger dock fördelen att det är riktigt billigt.

Vissa VPS-leverantörer i de dyrare tiers har dock riktiga SAN som har dedikerad IOPs . Där får du nog räkna med att du inte kan betala 2kr/GB.. utan det blir tiogånger så dyrt. Varför? Jo, riktiga SAN kostar.
För att få bra IOPs krävs ett bra storage backend, riktiga raidgrupper med många diskar. Jag har börjat skriva lite smått om detta på min blogg www.uppe.nu .

Vad du kan göra för att slippa diskläsningar är att skaffa mer RAM och allokera så att mySQL får nyttja det. En separat VPS/server hjälper också i och med att din apache slipper vänta på IOwait som orsakas av mySQL. Dock får du fortfarande vänta på resultat från din SQL oavsett om du lägger det på annan maskin - du måste alltså se till att optimera dina queries, köra memcached och andra cachningstekniker för att snabba upp local fetch.

Vad man dock får titta på om man ska göra en riktig analys är hur många av dina queries som är av respektive typ.
Sorts, writes, selects osv.
Writes taxerar disklagring mer än sorts och select som mer är läsning från RAM.
Du kan justera mySQL prestanda genom att konfigurera om så att den får göra dirty writes / updates. Dvs att det inte behöver synkas mot disk efter write och att en select får börja göras direkt utan att vänta på en write.

Då måste du dock på applikationslager se till så du kan hantera "fel" och ha vissa datakontroller.

Tillägg:
Ni kan förbättra prestanda i linux på filsystem genom att köra något journalförande filsystem som tillåter optimering/defragmentering.
T.ex. xfs .
Även om ext3 inte är så känsligt för fragmentering så kan det hända - ett system som varit igång länge blir lätt fragmenterat och diskprestanda blir lidande.
Xfs löser detta genom att du kan göra live optimeringar .

Jag har hittat problemet med min site och det beror INTE på diskprestandan eller VPS-leverantör utan helt enkelt på min egen sida som skapar låsningar i databasen. Låsningarna kommer först vid fler än 40 inloggade. Men jag gör om webb-applikationen för att inte få dessa låsningar.

Jag har tagit bort de delar som skapar låsningarna och då snurrar sidan på bra hos både Glesys och Citynetwork (City Cloud). Men visst har Glesys grymt mycket bättre diskprestanda, men enligt Citynetwork är det något de skall åtgärda under hösten/vintern.

Tack för alla hjälp och förslag som jag fått. Det har varit väldigt lärorikt.

mvh
Azone

;-) Skönt att det löste sig!

Ja, du hade helt rätt, det är/var låsningar. :)

Måste hitta något annat sätt att nå samma resultat bara, för det jag tvingades ta bort från sidan behöver jag i någon form.

Om inte ditt backend (disk IO) är snabbt nog så är det rätt troligt att du märker av låsningar vid updates/writes på din databas. Att lås får ske är helt normalt - det går inte alltid att skriva bort låsningar helt. Ett sätt att fuska sig förbi är att tillåta dirty reads (my.cnf förländring).

Kolla först och främst över din webbplatforms kod, sen kan du undersöka om det är annan flaskhals.

Han använder MyISAM och saknar därmed möjlighet att välja isolationsnivå, och för den delen förutsättningen att ens göra dirty reads.

Ah. Såg inte att han använde MyISAM (får skylla på kvällsarbete), då får han väl byta till InnoDB så snart han har möjlighet.
MyISAM och InnoDB har båda fördelar och nackdelar , MyISAM är snabbare om det inte sker massa updates / writes. Men troligtvis får han ut mer prestanda av InnoDB än MyISAM.