MySQL/webserver optimalisatie: php.ini/httpd.conf*

[TommyGun]

Beste Tweakers,

Al het een en ander heb ik gevonden en gelezen met betrekking tot de instellingen van zowel php.ini als httpd.conf, maar het is voor mij nogal onduidelijk wat nu de optimale (voor zover mogelijk) configuratie is. Natuurlijk hangt dit van het systeem af waarop dit (PHP/Apache) draait maar in hoeverre is dat van toepassing?

Zelf vind ik mijn webserver (site+forum) aardig draaien, maar ben toch benieuwd wat er nog veranderd zou kunnen worden aan mijn configs. Ik heb eigenlijk in de loop der tijd hier en daar wat aangepast, met de info die ik gevonden had, maar het blijft maar wat gissen en proberen (voor mij althans). Ik zou dus graag willen weten wat anderen zouden veranderen aan wat ik heb ingesteld.

Als eerste m'n server specs;


http://www.gamergun.com/phpsysinfo/

httpd.conf

code:

#
# Timeout: The number of seconds before receives and sends time out.
#
Timeout 240

#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive Off

#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
MaxKeepAliveRequests 500

#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection.
#
KeepAliveTimeout 10

##
## Server-Pool Size Regulation (MPM specific)
##

# prefork MPM
# StartServers: number of server processes to start
# MinSpareServers: minimum number of server processes which are kept spare
# MaxSpareServers: maximum number of server processes which are kept spare
# MaxClients: maximum number of server processes allowed to start
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule prefork.c>
StartServers       5
ServerLimit          500
MinSpareServers    5
MaxSpareServers   10
MaxClients       500
MaxRequestsPerChild  0
</IfModule>

# worker MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves
<IfModule worker.c>
StartServers         3
ServerLimit          500
MaxClients         150
MinSpareThreads     75
MaxSpareThreads     250
ThreadsPerChild     64
MaxRequestsPerChild  0
</IfModule>

php.ini

code:

;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 60     ; Maximum execution time of each script, in seconds
max_input_time = 120    ; Maximum amount of time each script may spend parsing request data
memory_limit = 1024M      ; Maximum amount of memory a script may consume (8MB)

; Maximum size of POST data that PHP will accept.
post_max_size = 25M

; Maximum allowed size for uploaded files.
upload_max_filesize = 25M

De rest lijkt me niet zozeer van toepassing. Ik moet er wel bij vermelden dat ik een uploadertje draai die bestanden van max 25MB accepteert, dus vandaar de ietwat hoge post_max_size en upload_max_filesize. Al weet ik niet of post_max_size veel te maken heeft met file uploads.

De Timeout van de httpd.conf heb ik dus ook redelijk hoog staan maar is dit wel nodig? Zolang er data verzonden wordt (als in; uploaden) dan kan er toch geen timeout optreden of wel?

Hopelijk kan ik hier dus wat kennis opdoen die ook weer te delen is met anderen die zich dit afvragen.

B.v.d

[ Voor 5% gewijzigd door TommyGun op 19-08-2007 22:44 ]

[Kalentum]

Zorg er in ieder geval voor dat je server nooit down kan doordat de geheugenruimte opgebruikt wordt. Als 'ie gaat swappen kan het zijn dat apache de requests niet meer kan bijbenen.

Dus die 1024Mb memory Limit zou ik weer terug zetten naar iets in de richting van 8Mb.

De script execution tijd van 60s weer terug naar 30 (een php request moet toch wel binnen 1s kunnen worden afgewikkeld, het kopieren van 25Mb data zou toch ook wel binnen die 30 s zijn afgewerkt).

voor het overige zal die 4Gb geheugen niet zo snel er voor zorgen dat je in de problemen komt.

[Verwijderd]

Vaak is er veel meer optimalisatie te behalen in de configuratie van je OS. Simpele dingetjes als DMA op je harddisks schelen *enorm* veel en worden niet door alle distributies standaard ingeschakeld. Ook neem ik aan dat je een SMP (of generic) kernel hebt geinstalleerd om allevier je CPU's te kunnen benutten? Ook analyseren welke andere scripts er nog op je server draaien is erg nuttig. Dingen als een logrotate of backup kosten ook resources!

[TommyGun]

rutgerw; memory limit heb ik op 512mb gezet, en script execution time verlaagd naar 30sec. Heb niet echt de behoefte om die memory limit nog veel lager te zetten, nog nooit problemen mee gehad althans. Bedankt voor de tips.

CyberKnutselaar; 2.6.9-27.ccsmp (SMP) volgens PHPSysInfo. Met top zie ik altijd wel processen switchen tussen alle CPU's dus dat lijkt te werken. DMA e.d. durf ik zo niet te zeggen, maar dit krijg ik als ik hdparm -tT /dev/sda run;

code:

/dev/sda:
 Timing cached reads:   904 MB in  2.01 seconds = 450.72 MB/sec
 Timing buffered disk reads:  164 MB in  3.02 seconds =  54.29 MB/sec

Ik zie verder niks in dmesg of iets met betrekking tot DMA, maar access times lijken me redelijk

Dank

[ Voor 3% gewijzigd door TommyGun op 19-08-2007 22:44 ]

[eghie]

Voor IO opdrachten is het mounten met noatime, nodiratime ook wel handig. Dit versnelt een hoop naar het schijnt. Ik gebruik het op elke Linux systeem.

doe eens hdparm -igtTI /dev/sda. (aarmee kun je geloof ik zien of DMA enzo aanstaat en wat gedetaileerde info van je HDD opvragen.)

APC vind je misschien ook nog wel leuk. Versnelt ook een hoop.

[killercow]

Noatime op je FS, reiserFS voor dingen als usericon's en mappen met meer dan 5k files of folders, en voor partities met aan avarage file size kleiner dan 64k.
Daarnaast kun je je apache aanpassen om zo minder threads open te houden nadat het avarage aantal seconden van een request burst vertreken is, (aka, hoe lang duurt een gemiddelde request burst, vast geen 15 seconde zoals apache nu wacht), maar das alleen maar echt interessant om geheugen te besparen waar je toch genoeg van hebt,

Verder kun je enorm veel snelheids wist maken door mysql gewoon echt veel geheugen te geven.
(2gb aan index, query en table cache)

[TommyGun]

eghie;

code:

[root@gateway ~]# hdparm -igtTI /dev/sda

/dev/sda:
 geometry     = 13263/255/63, sectors = 109093847040, start = 0
 HDIO_GET_IDENTITY failed: Invalid argument
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing cached reads:   856 MB in  2.01 seconds = 426.78 MB/sec
 Timing buffered disk reads:  160 MB in  3.02 seconds =  53.04 MB/sec

Hm ja het mounten met Noatime ken ik eigenlijk niet, en ik weet ook niet of het wel slim is daar mee te beginnen. Veel verder dan wat basis acties/commando's/whatever qua Linux kom ik nou ook weer niet. Alternative PHP Cache ziet er dan wel weer interessant uit, dat ga ik later 's bekijken.

killercow; RAM geheugen is idd het probleem niet, maar hoe kan ik MySQL veel geheugen geven? Je zegt index/query/table cache dus niet het proces zelf?

Bedankt beide

[killercow]

TommyGun schreef op maandag 20 augustus 2007 @ 18:44:
eghie;

code:

[root@gateway ~]# hdparm -igtTI /dev/sda

/dev/sda:
 geometry     = 13263/255/63, sectors = 109093847040, start = 0
 HDIO_GET_IDENTITY failed: Invalid argument
 HDIO_DRIVE_CMD(identify) failed: Invalid argument
 Timing cached reads:   856 MB in  2.01 seconds = 426.78 MB/sec
 Timing buffered disk reads:  160 MB in  3.02 seconds =  53.04 MB/sec

Hm ja het mounten met Noatime ken ik eigenlijk niet, en ik weet ook niet of het wel slim is daar mee te beginnen. Veel verder dan wat basis acties/commando's/whatever qua Linux kom ik nou ook weer niet. Alternative PHP Cache ziet er dan wel weer interessant uit, dat ga ik later 's bekijken.

killercow; RAM geheugen is idd het probleem niet, maar hoe kan ik MySQL veel geheugen geven? Je zegt index/query/table cache dus niet het proces zelf?

Bedankt beide

NoAtime is de manier om een webserver met veel kleine files veeeel sneller te maken, je hebt immers geen write meer nodig voor iedere request.

NoAtime geeft verder nergens problemen, je hebt alleen de kolom met last acces time niet meer correct gevuld.

In je my.cnf bestand kun je je memory limits voor mysql in stellen, deze zal wel in /etc/mysql/my.cnf staan.

Je query cache zou ik in jouw geval op 1gb zetten, je index mem op 128m of 64m, en de rest kun je ook wel een factor 8 verhogen.
Of dit nuttig is hangt dan natuurlijk ook weer af van je dataset, als je met 64meg ram je hele dataset + permutaties als gevolg van ingewikkelde queries kunt huizen heb je niets aan dat soort limits natuurlijk.
Met phpMyadmin kun je de status van je mysql server uitlezen en zo meteen de rood gekleurde kolommen opsporen, deze zijn volgens phpmyadmin aan de hoge kant, en er staat dan ook bij wat er mis zou kunnen zijn aan je code, je queries of je mysql instellingen.

[TommyGun]

/etc/mysql/my.cnf heb ik niet, wel /etc/my.cnf maar daar staat alleen dit in;

code:

[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1
     
[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

In /var/lib/ enzo zie ik zo vlug ook geen config files.

Hoe dan ook, even phpMyAdmin geopend en er zijn idd wel wat dingen rood, zal ze even opnoemen;

code:

Slow_queries    
3    
The number of queries that have taken more than long_query_time seconds.

Handler_read_rnd    
65 k    
The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.

Handler_read_rnd_next   
24 M    
The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

Created_tmp_disk_tables     
66      
The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.

Select_full_join    
62      
The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.

Sort_merge_passes   
494     
The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.

Opened_tables   
878      
The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.

Table_locks_waited      
46      
The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.

Verder is alles 'normaal' of groen. Misschien had ik beter eerst even de database kunnen optimizen, maar dit geeft een realistischer beeld. De database die het meeste gebruikt wordt is van mijn forum, Invision Power Board software, waar ook een redelijk aantal (custom-made) modificaties op zijn geinstalleerd dus het zal niet allemaal meer optimaal zijn maar sommigen getalletjes hierboven baren me toch wel wat zorgen.

Zal later eens kijken naar NoAtime, ben overigens ook bezig met APC.

Bedankt

[TommyGun]

Helaas wil APC niet...

'n Maat van me die wat meer van Linux weet heeft ook ff gekeken, en het gaat mis met PECL / PHP4 build files (daar mist ook van alles van) / phpize waardoor het hele zaakje niet werkt. ACP krijgen we dus ook niet geinstalleerd via PEAR. Heel wazig allemaal, gewoon 'n klote distro dat ClarkConnect / CentOS.

Hopelijk valt MySQL dan nog wat te optimaliseren, zie post hierboven. Dat mounten kijk ik morgen wel, heb nu wel weer genoeg Linux zooi gezien voor vandaag.

[ Voor 23% gewijzigd door TommyGun op 20-08-2007 22:44 ]

[eghie]

TommyGun schreef op maandag 20 augustus 2007 @ 22:43:
Helaas wil APC niet...

'n Maat van me die wat meer van Linux weet heeft ook ff gekeken, en het gaat mis met PECL / PHP4 build files (daar mist ook van alles van) / phpize waardoor het hele zaakje niet werkt. ACP krijgen we dus ook niet geinstalleerd via PEAR. Heel wazig allemaal, gewoon 'n klote distro dat ClarkConnect / CentOS.

Hopelijk valt MySQL dan nog wat te optimaliseren, zie post hierboven. Dat mounten kijk ik morgen wel, heb nu wel weer genoeg Linux zooi gezien voor vandaag.

Om phpize te hebben, moet je de package php5-dev installeren. Ik zie dat jij php4 gebruikt, dus dan moet je php4-dev installeren. Ik zou overigens voor PHP 5 gaan ipv PHP 4. De support voor PHP 4 vervalt in 2008 geloof ik. En PHP 5 is zelf ook sneller dan 4, omdat hij standaard de boel by reference meegeeft. Ook is het geheugen management van PHP 5 beter. En PHP 5 ondersteund geloof ik ook gewoon alle PHP 4 code.

[TommyGun]

Hehe dat PHP upgraden heb ik destijds eens geprobeerd, met alle gevolgen van dien. Heel deze distro versie raakt dan in de war en niks werkt dan meer. Iemand anders heeft het toen mogen fixen, wat niet zomaar gedaan was. Ik hou het dus lekker bij PHP4.

Maarre, php4-dev installeren heeft verder geen gevolgen voor huidige configs enzo? B.v.d

[TommyGun]

Edit; zie latere post

[ Voor 157% gewijzigd door TommyGun op 25-08-2007 18:18 ]

[creative8500]

TommyGun: zo'n hoge memory_limit is absurd. De limiet is er om veiligheidsredenen, zodat wanneer het geheugengebruik van een script out of bounds geraakt, je server niet nat gaat. Wanneer je script meer dan 8MB gebruikt is er hoogstwaarschijnlijk sowieso wat mis met het script.

[TommyGun]

Heb je ook wel gelijk in. Ik had 'm al naar 512M gegooid maar zal 's kijken, de helft daarvan is in principe nog wel genoeg.

Weet je toevallig iets over dat MySQL gebeuren?

[smesjz]

Wat ook veel scheelt: mpm_worker (of mpm_event bij apache 2.2) i.pv. prefork en zet gewoon je keepalive aan in httpd.conf. Verder kan je eens AllowOverride None zetten als je toch nergens een .htaccess gebruikt (of alles naar de httpd.conf kan verplaatsen)

Een grote mysql query cache is ook niet slim, je query cache wordt vaak geflushed bij tabellen die vaak wijzigen zoals bij een forum. Ik zou de waardes woon laten staan zoals ze nu staan.

noatime is idd een grote verbetering en ik zou zeker nog eens kijken naar PHP 5 die ook de nodige verbeteringen heeft.

[creative8500]

De helft van de helft van de helft van de helft van de helft van de helft zou al moeten voldoen.

[TommyGun]

@ smesjz; zoals je in de openings post kunt zien staan zowel prefork als worker geladen. Gewoon standaard zo... heb alleen wat getalletjes getuned. Kun je misschien iets specifieker zijn? Verder lees ik veel verschillende dingen wat betreft KeepAlive, en bij de meeste configs zie ik dit uit staan dus wat is nu slim?

Ik heb btw aardig wat verschillende .htaccess files hier en daar dus AllowOverride laat ik mooi zo staan. Bedankt voor de suggesties iig.

Edit, @ hierboven; heb 'm op 32M gezet, laag zat

Edit 2; wat betreft noatime, dat is een kwestie van mijn fstab veranderen van dit;

code:

LABEL=/1                /                       ext3    defaults        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

Naar dit?

code:

LABEL=/1                /                       ext3    defaults,noatime        1 1
LABEL=/boot1            /boot                   ext3    defaults        1 2
none                    /dev/pts                devpts  gid=5,mode=620  0 0
none                    /dev/shm                tmpfs   defaults        0 0
none                    /proc                   proc    defaults        0 0
none                    /sys                    sysfs   defaults        0 0
LABEL=SWAP-sda2         swap                    swap    defaults        0 0

[ Voor 71% gewijzigd door TommyGun op 25-08-2007 18:19 ]

[killercow]

smesjz schreef op dinsdag 21 augustus 2007 @ 22:22:
Wat ook veel scheelt: mpm_worker (of mpm_event bij apache 2.2) i.pv. prefork en zet gewoon je keepalive aan in httpd.conf. Verder kan je eens AllowOverride None zetten als je toch nergens een .htaccess gebruikt (of alles naar de httpd.conf kan verplaatsen)

Een grote mysql query cache is ook niet slim, je query cache wordt vaak geflushed bij tabellen die vaak wijzigen zoals bij een forum. Ik zou de waardes woon laten staan zoals ze nu staan.

noatime is idd een grote verbetering en ik zou zeker nog eens kijken naar PHP 5 die ook de nodige verbeteringen heeft.

de memmory limit van 8mb op php is inderdaaad best nuttig, deze vangt uiteindelijk meestal wel een eventuele endless loop, elke mb ram die je aan mysql geeft is beter besteed dan dat je hem aan apache of je disk cache geeft.

Een grote query cache is zeker wel nuttig, ook op een forum, je hebt immers altijd genoeg queries die wel blijven bestaan, denk alleen al aan de tabel met user info, of je forums zelf, deze worden nagenoeg nooit gerefreshd.

Ik bereken een dedicated machine altijd zo.
geheugen/2,
de ene helft voor apache en het OS, de rest voor mysql.
Van die helft geef 66% aan de query cache,
Van de rest geeft ik 50% aan de key buffers, en de rest verdeel ik over de overige settings die ik gebruik.
(aka, als je geen innoDB tables gebruikt deze wel mem geven, maar niet laten meedelen in de deling)
Vergeet niet om eventuele heap tables alvast van de mysql helft af te trekken zodat je met een realistisch beel blijft zitten en niet ineens 64meg mist.

De efficiency van de query cache kun je vrij gemakkelijk bekijken in phpMyAdmin, en geeft je een goed beeld van de nuttigheid van je memmory size.

Als je memmory te laag is blijf je onder de 50% hangen en zul je veel dumps zien wegens ruimte gebrek, als je een goede mem footprint hebt gekozen kun je afhankelijk van je app, meestal wel 90%= uit de cache serveren.

Wat nog veel meer helpt dan al deze platform optimalisaties is je key's nog eens nalopen, copy-paste de queries uit je code (of zet de slow query log aan en verwerk elke query tot je geen echt langzame meer hebt)

Let er op dat een langzame query eventuele snel hierop volgende queries ook kan vertragen omdat er door die quries op de table lock van je langzame query gewacht moet worden, helaas komen deze normaal gesproken queries dan ook in je slow_query_log.

Let er op dat het toevoegen van een index op je table de snelheid van schrijf acties verminderd, tenzij deze actie ook gebruik kan maken van de index.
Let er verder op dat een query in mysql maar 1 index kan gebruiken, welke de query gebruikt kun je zien door explain voor de query te plakken en hem zo in phpMyAdmin te executen.

Mysql kan verder van een multi-column index ook een gedeelte gebruiken, als je een index hebt gemaakt op ID,date,userid kan mysql deze index ook gebruiken voor een query met alleen ID of de combinatie ID,date. mysql kan deze index NIET gebruiken voor queries die zoeken op userid, aangezien deze data verkeerd opgeslagen staat in de index.

De ideale mix van indices is lastig te bepalen, maar daarom is het ook een truck, je kunt het niet altijd in een keer goed doen.

Eventueel zou je sharding kunnen gaan toepassen en je data kunnen gaan partitioneren, maar das weer een heel ander verhaal en hier ook niet nuttig (of je forum moet groter dan got zijn)

@tommy, dat is idd de eninge aanpassingen, even remounten en klaar.
Verder kun je apache nog tweaken geen gbruik te maken van .htaccess files oid, en ook kun je de default document in een keer goed zetten.
Mischien kun je dingen als user-icons nog en op 2e lighthttp draaien welke je keepalive geeft, op deze manier kun je de zwaardere apache gewoon op no keepalive zetten om zo de vrij zware php geladen threads weer vrij te geven voor de volgende single forum.php aan vraag, lighthttp kan immers de rest van de static content serveren.

[ Voor 9% gewijzigd door killercow op 21-08-2007 23:40 ]

[TommyGun]

Ik heb mount -o remount / uitgevoerd, dat is voldoende/juist? Gaf verder geen meldingen oid.

Uhm ja vanavond nog maar 's verder spelen met MySQL e.d.

De stats volgens phpMyAdmin;

code:

Handler_read_rnd    
34 k    
The number of requests to read a row based on a fixed position. This is high if you are doing a lot of queries that require sorting of the result. You probably have a lot of queries that require MySQL to scan whole tables or you have joins that don't use keys properly.

Handler_read_rnd_next   
10 M    
The number of requests to read the next row in the data file. This is high if you are doing a lot of table scans. Generally this suggests that your tables are not properly indexed or that your queries are not written to take advantage of the indexes you have.

Created_tmp_disk_tables     
19      
The number of temporary tables on disk created automatically by the server while executing statements. If Created_tmp_disk_tables is big, you may want to increase the tmp_table_size value to cause temporary tables to be memory-based instead of disk-based.

Select_full_join    
20      
The number of joins that do not use indexes. If this value is not 0, you should carefully check the indexes of your tables.

Sort_merge_passes   
317     
The number of merge passes the sort algorithm has had to do. If this value is large, you should consider increasing the value of the sort_buffer_size system variable.

Opened_tables   
180      
The number of tables that have been opened. If opened tables is big, your table cache value is probably too small.

Table_locks_waited      
13      
The number of times that a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimize your queries, and then either split your table or tables or use replication.

Het gaat me voornamelijk over de ''dit en dat (cache/buffer) is te laag, verhoog ze'' meldingen. Het maakt echt geen verschil hoe hoog ik dat ook gooi in mijn my.cnf, en anders begint dat TUNING PRIMER weer te zeiken dat ze te hoog staan.

Mijn my.cnf op dit moment;

code:

# The MySQL server
[mysqld]
port        = 3306
socket      = /var/lib/mysql/mysql.sock
skip-locking
max_connections=300
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 512
tmp_table_size=64M
sort_buffer_size = 16M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache = 8
query_cache_size = 64M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

tmp_table_size verhoogd van 32M naar 64M, sort_buffer_size van 2M naar 16M en query_cache_limit van 1M naar 8M.

Edit; dat laatste dacht ik dus, MySQL start niet eens met query_cach_limit = 8M erin.

Edit 2; merk geen snelheid winst met de noatime en MySQL aanpassingen. Zal later overigens weer eens tuning-primer.sh draaien en hier posten.

[ Voor 140% gewijzigd door TommyGun op 25-08-2007 18:26 ]

[TommyGun]

Om mezelf nog even te quoten;

Ik heb mount -o remount / uitgevoerd, dat is voldoende/juist? Gaf verder geen meldingen oid.

Daarbij heb ik MySQL even laten liggen (zie post hierboven!) en ben ik verder gaan prutsen met APC. Inmiddels php-devel-4.3.11-15.2.cc.i386.rpm geinstalleerd (na lang zoeken, 'mijn' apt-get kent geen php-devel, php-dev, php-4-dev, of wat dan ook) en nog wat andere configs aangepast.

Hoe dan ook, ik zag deze uitleg staan en daar ben ik atm mee bezig; http://www.vbulletin.com/forum/showthread.php?t=165367

Ik kom echter niet verder bij het volgende commando (uiteraard paths aangepast);

code:

./configure --enable-apc --enable-apc-mmap --with-apxs=/usr/webconfig/bin/apxs --with-php-config=/usr/webconfig/bin/php-config

Dit geeft;

code:

checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking whether gcc and cc understand -c and -o together... yes
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for PHP prefix... /tmp/cc-webconfig-engine-3.2-build/usr/webconfig
checking for PHP includes... -I/tmp/cc-webconfig-engine-3.2-build/usr/webconfig/include/php -I/tmp/cc-webconfig-engine-3.2-build/usr/webconfig/include/php/main -I/tmp/cc-webconfig-engine-3.2-build/usr/webconfig/include/php/Zend -I/tmp/cc-webconfig-engine-3.2-build/usr/webconfig/include/php/TSRM
checking for PHP extension directory... /tmp/cc-webconfig-engine-3.2-build/usr/webconfig/lib/php/extensions/no-debug-non-zts-20020429
checking for re2c... exit 0;
checking for gawk... gawk
checking whether apc needs to get compiler flags from apxs...

Sorry, I was not able to successfully run APXS.  Possible reasons:

1.  Perl is not installed;
2.  Apache was not compiled with DSO support (--enable-module=so);
3.  'apxs' is not in your path.  Try to use --with-apxs=/path/to/apxs
The output of /usr/webconfig/bin/apxs follows
apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server
apxs:Error: binary `/usr/webconfig/bin/httpd'.
configure: error: Aborting

Heb overigens geen idee waarom er 'n aantal keer /tmp/cc-webconfig-engine-3.2-build staat. Ik heb apxs al aangepast (daar stond namelijk telkens /tmp/cc-webconfig-engine-3.2-build) en nu kan ie alles wel vinden (voorheen niet) dus dat lijkt me weinig meer van toepassing.

Maar dus dat;

code:

apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server

Begrijp ik niet. Als ik namelijk /usr/sbin/httpd -l run krijg ik;

code:

Compiled in modules:
  core.c
  prefork.c
  http_core.c
  mod_so.c

Dus die module is gewoon ingeladen? mod_so.c kan ik echter nergens vinden (met locate). Uiteraard staat Perl geinstalleerd en zoals je ziet geef ik --with-apxs=/path/to/apxs mee dus daar kan het niet aan liggen.

Iemand suggesties? B.v.d

[eghie]

Apache 1 of Apache 2?

[TommyGun]

http://gamergun.com/version/

Apache 2.0. Moet ik dan apxs2 hebben? Daar las ik nml wel wat over, maar apt-get kon hem zo niet dus verder niet mee bezig geweest.

[ Voor 59% gewijzigd door TommyGun op 26-08-2007 19:34 ]

[eghie]

TommyGun schreef op zondag 26 augustus 2007 @ 19:33:
http://gamergun.com/version/

Apache 2.0. Moet ik dan apxs2 hebben? Daar las ik nml wel wat over, maar apt-get kon hem zo niet dus verder niet mee bezig geweest.

Dan moet je volgens mij inderdaad apxs2 hebben. Waarschijnlijk moet je dan ook apache2-dev installeren (daar zit die apxs2 in volgens mij). apt-cache search apache | grep dev (doet wonderen )

[ Voor 3% gewijzigd door eghie op 27-08-2007 07:24 ]

[TommyGun]

eghie schreef op maandag 27 augustus 2007 @ 07:21:
[...]

Dan moet je volgens mij inderdaad apxs2 hebben. Waarschijnlijk moet je dan ook apache2-dev installeren (daar zit die apxs2 in volgens mij). apt-cache search apache | grep dev (doet wonderen )

code:

[root@gateway ~]# apt-cache search apache | grep dev
apr-devel - APR library development kit
httpd-devel - Development tools for the Apache HTTP server.
apr-util-devel - APR utility library development kit

httpd-devel;

code:

The following extra packages will be installed:
  apr-devel apr-util-devel cyrus-sasl-devel db4-devel expat-devel
  openldap-devel pcre-devel
The following NEW packages will be installed:
  apr-devel apr-util-devel cyrus-sasl-devel db4-devel expat-devel httpd-devel
  openldap-devel pcre-devel

apt-cache search apxs kwam met;

code:

httpd-devel - Development tools for the Apache HTTP server.
mod_perl - An embedded Perl interpreter for the Apache Web server.

httpd-devel en mod_perl heb ik dus geinstalleerd, maar ik zie nergens iets verschijnen mbt apxs2.

code:

[root@gateway APC-3.0.14]# locate apxs
/usr/webconfig/bin/apxs

B.v.d

[TommyGun]

Iemand?

[TommyGun]

Bump

[eghie]

Het lijkt dat je toch apache 1.x hebt ipv apache 2.x. Ik gebruik zelf Debian en/of Ubuntu en daar heeft bij mij apache2-dev of apache2-threaded-dev het bestand /usr/bin/apxs2.

Maar aangezien ik ook PHP 5 heb, heb ik ook PECL. Dus ik kan APC installeren met het volgende commando: pecl install APC

[TommyGun]

Nouja; see for yourself @ http://www.gamergun.com/version/ . Ik heb dus geen apxs2, alleen apxs. Krijg echter niks gevonden met apt op apache2-dev / apxs2 of wat dan ook, verschillende dingen geprobeerd. Alleen dus die httpd-devel die al geinstalleerd staat.

pecl install APC werkt nu wel vreemd genoeg, lol. Laatste stukje;

code:

Libraries have been installed in:
   /var/tmp/pear-build-root/APC-3.0.14/modules

If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
   - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
     during execution
   - add LIBDIR to the `LD_RUN_PATH' environment variable
     during linking
   - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
   - have your system administrator add LIBDIR to `/etc/ld.so.conf'

See any operating system documentation about shared libraries for
more information, such as the ld(1) and ld.so(8) manual pages.
----------------------------------------------------------------------

Build complete.
(It is safe to ignore warnings about tempnam and tmpnam).

running: make INSTALL_ROOT="/var/tmp/pear-build-root/install-APC-3.0.14" install
Installing shared extensions:     /var/tmp/pear-build-root/install-APC-3.0.14/usr/lib/php4/
running: find "/var/tmp/pear-build-root/install-APC-3.0.14" -ls
9306997    4 drwxr-xr-x   3 root     root         4096 aug 31 20:16 /var/tmp/pear-build-root/install-APC-3.0.14
9307052    4 drwxr-xr-x   3 root     root         4096 aug 31 20:16 /var/tmp/pear-build-root/install-APC-3.0.14/usr
9307053    4 drwxr-xr-x   3 root     root         4096 aug 31 20:16 /var/tmp/pear-build-root/install-APC-3.0.14/usr/lib
9307054    4 drwxr-xr-x   2 root     root         4096 aug 31 20:16 /var/tmp/pear-build-root/install-APC-3.0.14/usr/lib/php4
9307051  268 -rwxr-xr-x   1 root     root       269371 aug 31 20:16 /var/tmp/pear-build-root/install-APC-3.0.14/usr/lib/php4/apc.so

Build process completed successfully
Installing '/usr/lib/php4/apc.so'
install ok: channel://pecl.php.net/APC-3.0.14
configuration option "php_ini" is not set to php.ini location
You should add "extension=apc.so" to php.ini

Dit heb ik aan de php.ini toegevoegd;

code:

extension=apc.so
apc.enabled=1
apc.shm_segments=1
apc.shm_size=128
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1

httpd gerestart;

code:

apc
APC Support     enabled
Version     3.0.14
MMAP Support    Enabled
MMAP File Mask  /tmp/apc.7SIVAv
Locking type    File Locks
Revision    $Revision: 3.140 $
Build Date  Aug 31 2007 20:16:30

Zou juist moeten zijn? B.v.d

Edit; http://gamergun.com/version/apc.php

Edit 2; zo, de parse times van m'n forum zijn echt flink omlaag gegaan zeg! Hopelijk geeft dit geen problemen met nieuwe posts die pas na 'n CTRL+F5 verschijnen ofzo.

[ Voor 6% gewijzigd door TommyGun op 31-08-2007 20:51 ]

[TommyGun]

Om vervolgens eens terug te komen op MySQL;

code:

        -- MYSQL PERFORMANCE TUNING PRIMER --
             - By: Matthew Montgomery -

MySQL Version 4.1.12 i686

Uptime = 8 days 2 hrs 32 min 51 sec
Avg. qps = 3
Total Questions = 2688947
Threads Connected = 1

Server has been running for over 48hrs.
It should be safe to follow these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/4.1/en/server-system-variables.html

SLOW QUERIES
Current long_query_time = 10 sec.
You have 3 out of 2688959 that take longer than 10 sec. to complete
The slow query log is NOT enabled.
Your long_query_time may be too high, I typically set this under 5 sec.

WORKER THREADS
Current thread_cache_size = 8
Current threads_cached = 6
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 300
Current threads_connected = 1
Historic max_used_connections = 18
The number of used connections is 6% of the configured maximum.
You are using less than 10% of your configured max_connections.
Lowering max_connections could help to avoid an over-allocation of memory
See "MEMORY USAGE" section to make sure you are not over-allocating

MEMORY USAGE
Max Memory Ever Allocated : 803 M
Configured Max Per-thread Buffers : 7 G
Configured Max Global Buffers : 330 M
Configured Max Memory Limit : 8 G
Total System Memory : 5.62 G

Max memory limit exceeds 85% of total system memory

KEY BUFFER
Current MyISAM index space = 26 M
Current key_buffer_size = 256 M
Key cache miss rate is 1 : 419
Key buffer fill ratio = 16.00 %
Your key_buffer_size seems to be too high.
Perhaps you can use these resources elsewhere

QUERY CACHE
Query cache is enabled
Current query_cache_size = 64 M
Current query_cache_used = 7 M
Current query_cach_limit = 1 M
Current Query cache fill ratio = 11.80 %
Your query_cache_size seems to be too high.
Perhaps you can use these resources elsewhere
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 16 M
Current record/read_rnd_buffer_size = 7 M
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 132.00 K
You have had 100 queries where a join could not use an index properly
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.
If you are unable to optimize your queries you may want to increase your
join_buffer_size to accommodate larger joins in one pass.

Note! This script will still suggest raising the join_buffer_size when
ANY joins not using indexes are found.

OPEN FILES LIMIT
Current open_files_limit = 1510 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_cache value = 512 tables
You have a total of 367 tables
You have 317 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 16 M
Current tmp_table_size = 64 M
Of 1970 temp tables, 0% were created on disk
Effective in-memory tmp_table_size is limited to max_heap_table_size.
Created disk tmp tables ratio seems fine

TABLE SCANS
Current read_buffer_size = 1 M
Current table scan ratio = 200 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 2056
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

My.cnf; http://www.gamergun.com/files/1/my.cnf
httpd.conf; http://www.gamergun.com/files/1/httpd.conf

Iemand nog suggesties daarvoor misschien? Lijkt erop dat ik teveel ram weggeef, maar ik krijg 't totaal niet echt lager.