RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]location / {
if (!-e $request_filename){
rewrite ^(.*)$ /index.php?q=$1 break;
}
}server {
listen 80;
server_name domain.com www.domain.com;
root /var/www/domain.com/htdocs;
location ~ \.php$ {
include fastcgi.conf;
try_files $uri =404;
fastcgi_intercept_errors on;
fastcgi_pass 127.0.0.1:8000;
}
}[test]
listen = 127.0.0.1:8000
user = test
group = test
pm = dynamic
pm.start_servers = 2
pm.max_children = 5
pm.min_spare_servers = 2
pm.max_spare_servers = 2nano /etc/php-fpm.d/test.confecho "Hello World" > /var/www/domain.com/htdocs/test.htmlecho '<?php phpinfo(); ?>' >> /var/www/domain.com/htdocs/phpinfo.php
ps -ylC php-fpm --sort:rss | awk '!/RSS/ { s+=$8 } END { printf "%s\n", "Total memory used by PHP-FPM child processes: "; printf "%dM\n", s/1024 }'
S UID PID PPID C PRI NI RSS SZ WCHAN TTY TIME CMD
S 502 9752 9749 0 80 0 4196 71005 inet_c ? 00:00:00 php-fpm
S 502 9753 9749 0 80 0 4196 71005 inet_c ? 00:00:00 php-fpm
S 501 9754 9749 0 80 0 4196 71005 inet_c ? 00:00:00 php-fpm
S 501 9755 9749 0 80 0 4196 71005 inet_c ? 00:00:00 php-fpm
S 0 9749 1 0 80 0 5020 71022 ep_pol ? 00:00:04 php-fpm
S 504 13999 9749 0 80 0 29856 76613 skb_re ? 00:00:01 php-fpm
S 504 13993 9749 0 80 0 33620 77530 skb_re ? 00:00:02 php-fpm
S 504 13998 9749 0 80 0 33768 77659 skb_re ? 00:00:01 php-fpm
S 504 13994 9749 0 80 0 35992 79313 skb_re ? 00:00:01 php-fpm
S 504 13991 9749 0 80 0 37092 79761 skb_re ? 00:00:01 php-fpmTotal memory used by PHP-FPM child processes:
188M[20-Jun-2013 08:33:31] WARNING: [pool rstefanov.org] server reached pm.max_children setting (10), consider raising it
Ами тествах го уж вървеше добре, но после почна на 2 от сайтовете да дава грешка явно като се препълни кеша на APC 96M, като го изключих грешката изчезна. Имаше го и момента че php-fpm нещо не приемаше никакви други потребители за mysql(MariaDB) освен root, при apacheto си работеха.
То точно към пробния сървър насочих dns и те. Синхронизирах първо качих ресурсите до същото равнище и насочих временно вечерта да видя как ще тръгне. Но като видях че и RAM а скача много върнах към стария сървър.
На ден: Около 14 000 посещения, 9000 уникални, 55 000 импресии, Макс онлайн около 300-350
Това са долу горе общо за новинарските сайтове които са 4 на брой.
На сървъра има още 6 сайта, но за тях ползвам един модул който ги кешира до html и се обновява кеша много рядко. Те са бизнес сайтове и към тях няма толкова посещения и не се изпълнява php. Да кажем още около + 500 посещения и за тях общо.
В момента сървъра е с Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz, 5 cores 2GB RAM и преди малко пак имаше голямо натоварване и блокира тотално. Едвам се рестартираше. Но обикновено като е с такива параметри върви добре случва се по рядко да има проблем.
Преди беше на Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz, 4 cores 1.6GB RAM. Но с тези параметри забива по няколко пъти на ден и за това ги качвам сутрин и ги връщам вечерно време на старите.
Проблемите реално са между 11:30 - 17:30, през останалото време си работи добре. Но като гледам през tyxo-то няма чак толкова много посетители онлайн макс да стигат 300-350 за всички общо и импресиите се качват нормално все пак някои четат нещо през това време други може даже вече да са излезли.
Нека първо оправя сайтовете да споделят общ код от едно място и ако има нещо ще пиша, даже мога като са готови нещата да ти дам достъп да хвърлиш едно око на бързо.
Ами това e VM на cloud server.
Защото аз се запознах с linux официално преди има няма една седмица. В смисъл някои основни неща ги знаех, налага се като web developer да правиш някои неща по сървъра но общо взето нещата се свеждаха до yum install и администрация през webmin
Преди ми малко като блокира ми писаха от хоста че проблема е бил че MySQL генерирало високо дисково натоварване и след reair и optimize се оправило.
Имам една innodb база данни за най-натоварения и останалите са myisam, мисля да ги конвертна всичките на xtradb и да мина на percona server мислиш ли че това би подобрило нещата. В сайта им пише че натоварването с техния сървър било по малко и по предсказуемо без внезапни пикове и самия storage бил по добър.
не че има лошо да го решиш генерално и веднъж завинаги както r.stevanov предлага и това е за сингъл инсталация значи те така или иначе препоръчват веднъж на ден да си чистищ апц кеша за да не се фрагментира много аз ти казвам на база четене на уебхостинг талк пусни го веднъж с един крон веднъж на час да го чисти ще имаш само няколко минути по бавна работа докато го понапълни и няма да го мислиш токова
заедно с htop. yum install htop (има го в epel репоса).