Hej igen

Tack för att ni flyttade tråden så att det blir rätt.

Här kommer lite mer info om sajten och vad vi använder:

Vi kör Apache 2 med PHP5 och MySQL. PHP körs som: FCGId (run as virtual server owner). Virtualmin går inte långsamt när sajten gör det. Sajten har ungefär samma belastning kl 13-23 men går som segast kvällstid.


AWSTATS REPORT 1-6 AUGUSTI

Första besök 01 Aug 2011 - 00:00
Senaste besök 06 Aug 2011 - 23:37

Unika besökare
392603

Antal besök
981776

Sidor
2548403

Träffar
7248607

Byte
27.54 GB


VIRTUALMIN SYSTEMINFO

System hostname
debian

Operating system
Debian Linux 5.0

Webmin version 1.550

Virtualmin version
3.87.gpl GPL

Theme version 8.1

Time on server 07/Aug/2011 16:34

Kernel and CPU
Linux 2.6.26-2-amd64 on x86_64

CPU load averages
0.05 (1 min) 0.16 (5 mins) 0.13 (15 mins)

Running processes
268

Real memory
3.88 GB total, 1.53 GB used

Virtual memory 870.67 MB total, 1.42 MB used

Local disk space
18.38 GB total, 5.69 GB used

Nu fanns det mer info :D Generellt arbetar vps:en inte speciellt hårt, du har även gott om minne och den verkar inte ha hög io-wait. Men mysql som jobbar eventuellt lite för hårt, installera gärna mtop och se om några sql frågor ligger och tar för lång tid. Själva php-skriptet, har ni programmerat det själva? Har ni rätta index skapade? Vad kör ni för sql-cachning samt använder ni någon opt-kod cache? Val av programvaror verkar var rätt bra, även om det optimala hade varit att ni kört nginx och php-fpm. Men jag skulle även vilja se configen från /etc/apache2/apache2.conf samt /etc/mysql/my.cnf. Jag gissar att ni kör apache2 prefork och eftersom ni kör fcgi på php kan ni köra worker om ni inte redan gör det.

Jag tror liksom Danielos att det kan vara några SQL-frågor som blockerar upp. För mycket skrivoperationer till MyISAM-tabeller med hyffsad storlek är det vanligaste när en sajt börjar växa. Problemet då är att MyISAM-motorn låser hela tabellen istället för såsom t ex innodb som låser på radnivå. Resultatet blir att alla läsoperationer som pågår under den mycket tyngre skrivoperationen måste vänta på att låset hävs. Det är ett vanligt problem för en förhållandevis slumpvis seg sida under peak-tider.

Annars är två vanliga fcgi-problem att antalet fcgi-processer inte räcker till eller att varje process får hantera för få requests. Hur dessa uppenbarar sig när du kör det via apache är jag inte helt 100 på dock.

Hej igen

Här kommer en skärmdumt med mtop.

* PHP-scripten har vi gjort själva
* Databasen är gammal men "utbyggd". Har lagt till diverse index men vi gör en hel del SELECT som inte använder index i WHERE-satsen.
* Dock går några riktigt tunga admin-frågor för att kolla statistik utomordentligt snabbt. Tar 2-4 sekunder nu som kanske tog 10-15 hos Binero.

Skickar med en kopia på det jag tror är apache2-config filen.

Vet inte hur jag får tag i my.cnf? Kom åt apache2.cnf via virtualmin.

Kollade i tmp-mappen på servern och det ligger fasligt mycket sessions-filer sparade där. Kan det vara några problem med det? Runt 20.000 sessions-filer, alla skapade senaste timmen.

"Vad kör ni för sql-cachning samt använder ni någon opt-kod cache?"
* Har tyvärr ingen aning om vad detta är...

"Jag gissar att ni kör apache2 prefork och eftersom ni kör fcgi på php kan ni köra worker om ni inte redan gör det"
* Ingen aning om vi kör det eller inte.

Mvh
Johnny

my.cnf hittar du enklast genom att skriva
locate my.cnf
i kommandoprompten. Då får du ut sökvägen till filen. Det kan också vara så att du inte har någon på servern, och då går MySQL mot de hårdkodade defaultvärden som finns inne i databasmotorn. Men sannolikt finns det en fil i filsystemet.

my.cnf kan finnas på flera ställen, och den kopierade texten nedan informerar om vart den finns.
"The location of my.cnf is searched in the order of:
global options - /etc/my.cnf,
server-specific options - /usr/local/mysql/data/my.cnf,
user-specific options - ~/my.cnf"

Källa: http://www.devside.net/guides/linux/mysql

Om det nu är så att det är databasen som ställer till det för dig, bör du aktivera slowloggen och låta den logga några timmar (eller dagar eller minuter beroende på besökarmängden). Därefter analyserar du loggfilerna och du kommer då att få reda på vilka frågor som är tyngst att köra.

Värt att notera är att slowloggen i sig är prestandakrävande så se till att stänga av den när den inte behövs.

Mer info om slowqueryloggen
http://dev.mysql.com/doc/refman/5.0/...query-log.html

Men vem har instalerat servern? Att själv administrera och köra en egen server/vps med så pass små kunskaper är inget som någon på wn skulle rekommendera. Du bör även lära dig att in via ssh logga in på kommandopromten och jag tycker generellt att du bör lära dig administrera en burk ordentligt alternativt hitta någon som kan.

Generellt tycker jag, eftersom jag tror ni kör myisam är att ni bör se till att statistik ligger in en separat databas, för det är gararanterat statistik skrivningarna som låser databasen för mycket, men ni bör inte läsa in från databasen varje gång en besökare träffar siten, eller gör ni det? Ni bör antingen cacha resultatet eller spara datan i cookies.

Vi har ganska lite erfarenhet av köra en egen server men vi lär oss varje dag och tar hjälp när vi behöver :)

Har försökt testa det mesta av alla förslag och har trimmat databasfrågorna.

* Tror inte det är MySQL som är problemet. Har analyserat mtop en längre tid nu och det är inga frågor som tar längre än ett par sekunder max. Endast frågor vi kör som admin för statistik m.m. som är krävande där det som mest tar 15 sek. Dessa kör vi dock endast ett fåtal gånger per dag och då oftast som schemalagda cronjobs.

* Den största tabellen har ungefär 500.000 rader och är innoDB.

* Kör även en del php-sidor på samma konto som inte har databasanslutningar alls. Dessa sidor går också långsamt att ladda när övriga sidan laddar trögt. Dock fungerar Virtualmins gränssnitt snabbt i alla lägen.

* Känns som att "domänen" inte svarar helt enkelt när det går segt. Domän ligger fortfarande hos Binero.
Sajten är ju skapad som en "virtual server" i Virtualmin. Det finns bara en virtuell server på hela maskinen.

* Känns som att det är nån begränsning eller nåt värde som stoppar mycket trafik mot själva virtuella servern och inte mot hela maskinens config.

Ok, det låter bra :)
Virtualmins skulle jag tro har egen webbserver installerad.

En domän kan inte gå segt, det spelar ingen roll vart den ligger, det som spelar roll är var siten ligger, en domän endast pekar till sitens IP.

Det känns som det är något med apache2/fcgi som inte lirar riktigt, och med den info som finns hittills där man inte ens vet exakt hur det körs kan åtminstone inte jag hjälpa till. Men det känns som ni behöver ta hjälp av någon som antingen fixar configen bra eller installerat nginx/php-fpm istället.

Ja, att ta hjälp utifrån är nog den enda lösningen tror jag snart.

All kod och queries har vi skrivit själva ja. Databasen är gammal men uppdaterad och utbyggd.

* Vi har en fil på servern som används överlägset mest och som säkert står för mer än 90% av trafiken. Loggade visningarna av denna fil under
3 minuter kl 14 idag och den gav då 357, 384 respektive 422 visningar per minut under 3 minuter.

* Den filen har några databasfrågor men inget som borde vara märkvärdigt.

* Om vi istället för att ladda denna sidans innehåll och bara skriver ut en tillfällig text med PHP så fortsätter ändå servern att svara lika segt. I mtop sjunker QPS från 30-110 till 2-20 ungefär så den mesta databasbelastningen försvinner då men fortfarande lika segt.

Kan börja med att säga att jag inte är något expert på just detta, men lite koll har jag i alla fall.

Låter som det är någon konfiguration i apache som inte är riktigt som den ska.

Du har ju ganska höga värden på trådar och klienter, men det kanske blir bättre om du höjer ytterligare. Testa även att sänka keep alive-värdena.

Prestandan skulle nog må bra av att du köp apache i worker mode istället för prefork(som jag antar att du kör nu).
Annars är Nginx med PHP-FPM ett väldigt bra alternativ. Det är bara att installera via aptitude/apt nu förtiden då PHP-FPM numera är inkluderat i php-paketet.
Ett tredje alternativ är att installera någon reverse proxy framför webbservern men det är nog lite mer komplicerat.