Оптимизиране на Apache PHP PostgreSQL, Hostinfo
В някои форуми имаше препоръка също да се зададе pgsql.auto_reset_persistent = On за откриване на "прекъснати" връзки, но или "прекъснатите връзки" са много редки, или се появяват някак си незабележимо. С други думи, не можете да направите това. Можете да зададете ограничение за връзка в PHP, като оставите pgsql.max_persistent = -1 pgsql.max_links = -1
Ефектът от преминаването към постоянни връзки е много забележим, особено на сайтовете, които посещавате. Зареждането веднага спада с двадесет или тридесет процента или дори повече. Просто не се плашете, когато намерите куп postres в горната част в състояние sbwait.
PostgreSQL се конфигурира чрез редактиране на файла postgresql.conf и след това рестартиране на postmaster. Въпреки факта, че някои параметри могат да се променят в движение, практиката показва, че пълното рестартиране позволява много по-точно и по-бързо проследяване на въздействието на определени промени в конфигурацията върху поведението на системата като цяло, така че има смисъл да се използва този конкретен метод.
Следващият полезен параметър еsort_mem. Тази памет се използва за сортиране на получените набори от данни и голяма част от нея е полезна, ако вашите заявки често използват SELECT. ПОДРЕДЕНИ ПО. Но трябва да бъдете много внимателни с този параметър - не само количеството памет, което сте посочили, се разпределя за всеки процес, но може да се разпределя и няколко пъти за сложни заявки! Така че също си струва да играете с този параметър - опитайте да промените стойностите му в диапазона, да речем, от 1 MB до 128 KB. Освен това понякога резултатите са парадоксални - намаляването на паметта води до повишаване на производителността - очевидно поради създаването на много малки временнифайлове, които операционната система успешно кешира в свободната памет.
Оптимизирането на самите SQL заявки, особено тези, които се използват най-често, също може да доведе до добра печалба в производителността. За да ги изчислите, можете да преномерирате всички заявки в скриптове и да запишете номера на заявката в дневника (или таблицата) преди всяко извикване на pg_query(). И след това просто анализирайте дневника. За да видите как ще се изпълни заявката, можете (и трябва!) да използвате командата EXPLAIN. Имайте предвид, че в някои случаи дори просто да промените реда на условията за избор в клаузата WHERE може да промени плана за изпълнение на заявката!
използването на изгледи (VIEWS)също може да помогне в някои случаи. Факт е, че когато издава "нормална" SQL заявка, сървърът я анализира, създава план за изпълнение и след това го изпълнява. И ако се използва представяне, тогава анализът и изготвянето на план се извършват само когато е създаден. Ако заявките се изпълняват често, спестяванията на процесорно време могат да бъдат доста осезаеми. Да не говорим за факта, че заявките в скриптовете ще станат много по-кратки и по-ясни.
Тук можете да използвате следния трик - докато VACUUM работи, пренасочете посетителите към страница с обяснения, че тече профилактика и сървърът ще възстанови работата си след няколко минути. Когато използвате уеб сървъра на Apache, това се прави лесно с помощта на mod_rewrite: вашият оптимизационен скрипт създава и изтрива файла /home/site/optimizer.pid при стартиране, а mod_rewrite е активиран в Apache и е посочен RewriteCond /home/site/optimizer.pid -f RewriteRule .* /optimization_message.html
За да намалите времето, през което посетителите не могат да стигнат до вашия сайт, можетепренасочват посетителите само в момента, в който се оптимизират големи и често използвани таблици, а останалите "чистят" паралелно с работата на сайта. Ако данните в базата данни се актуализират много често, тогава можете, да речем, да стартирате VACUUM ANALYZE на всеки час и веднъж на ден - VACUUM FULL ANALYZE. Като правило, "времето на престой" на сървъра с този подход може да бъде намалено до една или две минути, дори на много големи сайтове.
Разбира се, структурата на вашата база данни също има много голямо влияние върху производителността, но тази област зависи много от задачите и няма да бъде разгледана в тази статия.
Конфигурационният файл на Apache обикновено се намира в /usr/local/apache/conf/httpd.conf и можете да принудите сървъра да го прочете отново с помощта на програмата /usr/local/apache/bin/apachectl.
Основната цел на следните препоръки е да се определи и ограничи броя на работещите Apache във всеки даден момент (ако приемем, че самият сървър вече е конфигуриран и работи). Факт е, че (условно) един процес на Apache се "харчи" за всеки посетител на сайта и всеки такъв процес консумира памет и процесорно време. Следователно, ако имате твърде много работещи сървъри, тогава няма да има достатъчно RAM и използването на swap ще забави значително сайта. От друга страна, ако има малко работещи сървъри, тогава, когато потребител влезе, ще бъде изразходвано време за създаване на нов процес, което отново води до забавяне и време на процесора.
От изложеното по-горе става ясно, че от една страна е желателно винаги да има някакъв резерв от работещи сървъри, които да обслужват посетителите, а от друга страна е необходимо да се убиват допълнителни сървъри, за да не се губи твърде много памет. Ясно е, че специфичниЧислата зависят от трафика на вашия уебсайт и наличните ресурси, така че числата по-долу трябва да се използват само като базова линия, като се коригират, ако е необходимо.
Максималният брой Apache, които могат да работят едновременно, се определя от параметъраMaxClients. Този брой трябва леко да надвишава максималния брой посетители, които в даден момент могат да бъдат на вашия сайт. В същото време, ако има много хора, които искат да стигнат до вас, и няма достатъчно сървърни ресурси, за да ги обслужват, тогава прекалено голям брой работещи сървъри само ще забави цялата работа. Затова е желателно да се постави някаква разумна граница, да речем 150 или 200.
Времето, през което сървърът чака отговори от клиента, се определя от параметъраTimeout. Понякога се случват прекъсвания на комуникацията и ако браузърът на посетителя се свърже с вашия сървър, не получи отговор и изпрати втора заявка (да речем, потребителят натисна презареждане), тогава ще стартирате два Apache, а единият от тях просто ще виси и ще изчака определеното време, когато посетителят потвърди желанието си да прегледа страницата. По подразбиране този параметър е зададен на 300 секунди, но се оказа много по-ефективно да се намали до 30.
Активирането на поддръжка заKeepAliveможе да направи живота много по-лесен. Факт е, че в "нормален" режим, за да прехвърли всеки файл, клиентът трябва да установи връзка и ако имате например 10 снимки на страницата, ще трябва да установите и прекъснете 10 връзки, за да ги прехвърлите. А в режим KeepAlive сървърът не прекъсва връзката след прехвърлянето на файла и обработва последващи заявки от този клиент, използвайки вече установена връзка. По този начин се спестява време за настройка и прекъсване на връзки и запопулярни сайтове тази разлика може да бъде много забележима!
За KeepAlive връзки, както и за нормални връзки, трябва да зададете времето за изчакване с помощта на параметъраKeepAliveTimeout. Тъй като сървърът, който е установил връзка с клиент, не е достъпен за други клиенти, докато връзката не бъде прекъсната, твърде висока стойност може да доведе до това, че куп сървъри не правят нищо и просто чакат да видят дали техният клиент иска да изтегли нещо друго. И в същото време, тълпа от нови посетители може да открие, че вашият сайт не отговаря, тъй като максималният брой разрешени Apache е достигнат. Най-практичната стойност за параметъра KeepAliveTimeout е нещо между десет и двадесет секунди.
Както знаете, използването на програма за дълго време може да доведе до "изтичане на памет" или някои други ресурси. За да избегнете подобни проблеми, има два параметъра:MaxKeepAliveRequestsиMaxRequestsPerChild. Първият параметър е отговорен за принудителното "убиване" на процеса след обработка на зададения брой KeepAlive заявки, а вторият - след посочения брой "нормални" заявки. По принцип не трябва да има изтичане на памет в по-голямата част от системите и тези параметри могат да бъдат направени доста големи - няколко хиляди всеки. Но за всеки случай следете поведението на сървъра - възможно е да бъдат открити "течове" в някои от библиотеките, които използвате. Най-удобно е да се движите "отдолу нагоре" - първо задайте стойностите да бъдат малки, да речем 100 и 50, и след това да ги увеличите, като наблюдавате поведението на сървъра.
Е, и още три параметъра, които регулират броя на изпълняваните процеси:StartServers,MinSpareServersиMaxSpareServers. Първият, при стартиране на сървъра, стартира посочения брой "апачи". Второто определяминималният брой неактивни сървъри, чакащи нов клиент, а третият - техният максимален брой. Като първа стъпка можете да опитате да речем 25, 2 и 10 и след това да погледнете натоварването на сайта.
Най-лесният начин бързо да оцените въздействието на вашите промени върху вашите настройки е да използвате командата top. В горната част на прозореца, когато работи, се показва полезна статистическа информация, нещо подобно:
На първо място, трябва да обърнете внимание на средните стойности на натоварването - колкото по-високи са числата, толкова по-лошо. В идеалния случай в нормално състояние те не трябва да надвишават единица. Следващото нещо, което трябва да разгледате, е използването на суап файла. Вдясно от реда за размяна може да се появят съобщения за запис в суап файла (Page Out) или четене от него (Page In). Колкото по-често се появяват такива съобщения, толкова по-зле. Дисковите операции са много бавни. И, разбира се, трябва да следите количеството свободна памет и натоварването на процесора. Ако обаче успеете да постигнете ситуация, при която суап файлът няма да се използва, тогава най-вероятно всичко останало бързо ще се върне към нормалното.