Și niște grafice pe ultima oră (cu ocazia asa am văzut că trebuie să am o discuție mai îndeaproape cu softul de monitorizare - are mici clipe de amnezie)
zup: ca server de web prefer apache-ul cu patch-uri de securitate al lui OpenBSD.
memcached: din câte am văzut necesită modificăti la nivel de PHP în Expression Engine. Eu nu mă bag. Revenim la problema cu lipsă programator.
mysqld-ul este criminalul - dă în disc și în cpu rău de tot - scrie într-una.
memcached: din câte am văzut necesită modificăti la nivel de PHP în Expression Engine. Eu nu mă bag. Revenim la problema cu lipsă programator.
acolo ma pot baga eu. probabil ca sunt multe query-uri sau blocuri intregi care pot fi salvate in cache.
o sa ma uit pe link-ul asta in weekend sa vad ce-i cu el (nu stiu ce incude core-ul): https://secure.expressionengine.com/download.php
se poate sa castigam performanta si prin mutarea cache-ului deja existent in memcache, dar trebuie vazut.
log_slow_queries = /var/log/mysql/mysql-slow.log # aici pui si tu un director unde are voie mysql sa scrie (gen /tmp)
long_query_time = 2 # “slow” inseamna >= 2 secunde/query
log-queries-not-using-indexes # e evidenta
relativ la treaba cu sort, uite unde trebuie sa te uiti (quoted direct de pe net):
Look at sort_merge_passes in SHOW GLOBAL STATUS. It’s worth considering increasing sort_buffer_size if it’s increasing rapidly, and not if it’s increasing slowly or not at all.
[ Modificat: 14 Octombrie 2009 07:27 AM de sigxcpu ]
Încearcă să pui o copie a bazei de date pe serverul acela pe care ți l-am dat. Chiar dacă pe moment sunt doar 100Mbps disponibili, eu zic că o să facă față încă vreo două săptămâni, până când îmi vine adaptorul de rețea 1000BaseSX din statele alea unite.
@jeffe: daca are masina si nu foloseste resursele (vezi RAM) pt. ca este prost configurat, ce te face sa crezi ca pe o noua masina o sa mearga mai bine, in afara de brute upgrade la viteza/nr CPU?
un sofer prost e la fel si pe dacie si pe mercedes.
modificări în my.cnf din recomandările lui sigxcpu + tuning-primer.sh :
key_buffer = 128M # scăzut de la 256Mb deoarece era 81% nefolosit sort_buffer_size = 32M # crescut de la 2Mb (sort_merge_passes e 974 dupa 34 de zile de uptime) join_buffer_size = 32M # crescut de la 1Mb table_cache = 2048 # crescut de la 512 care era folosit 100% și dădea un hit-rate de doar 24% log-slow-queries = /var/log/mysql-slow.log long_query_time = 2 log-queries-not-using-indexes
mysql> show status like 'Created%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | Created_tmp_disk_tables | 0 | | Created_tmp_files | 1953 | | Created_tmp_tables | 1 | +-------------------------+-------+ 3 rows in set (0.01 sec)
tuning-primer.sh se plânge de asta:
TABLE LOCKING Current Lock Wait ratio = 1 : 55 You may benefit from selective use of InnoDB. If you have a high concurrency of inserts on Dynamic row-length tables consider setting 'concurrent_insert=2'.
Și am mai crescut eu niște parametrii de kernel legați de câtă memorie să acloce pentru filesystem caching & friends.
Ii dau un reboot la server cu toți parametrii noi și vedem ce iese.
jeffe: mai încercăm un pic să extragem tot untul din cutia asta argintie și dacă nu reușim, sar pe mysql-ul tău. Mulțumesc încă odată.
[ Modificat: 14 Octombrie 2009 09:32 AM de psergiu ]
Eu zic ca in 5 minute de plimbat prin forum putem agata toate situatiile naspa.
E posibil sa iasa mare, baga-l si tu la un rapidshare and shit si da-o pe PM (sunt date pe acolo, probabil parole criptate, dar sunt date de user gen name, cred).
