Ağır yük için VPS'de çalışan apache / php / mysql'i optimize edin

512m RAM ile bir VPS'de apache / mysql sunucusunu optimize etme hakkında soru. Normal yük altında her şey hızlı çalışır, bağlantı gecikmesi olmaz. Ancak yoğun trafik günlerimizi (50 bin + ziyaret) aldığımızda site taranır ve içeriği apache'den geri almak 30 saniye + sürer.

Site, Expression Engine (CMS) (PHP'de) üzerinde çalışıyor ve ağır yük optimizasyon kılavuzunu takip ettim. Ben googled ve biraz şans ile apache için orada birkaç takip ettim, şimdi nerede olsun, ama sürekli tepki süreleri almak gerekir.

Ben yeterli RAM (burada yapmaya çalıştığım için) var gibi burada 'düşük bellek için optimize' sorusu farklı olduğunu varsayalım, sadece ağır yük altında boğulmak için sunucu almak gerekir.

Herhangi bir öneriniz var mı?

PHP için kapasiteyi artıracak 2 önemli şey vardır:

1. Gelişmiş PHP Önbellekleme (APC) olarak bahsedildi. Yahoo'da kullandığımız şey budur. Başka benzer projeler var, ama bu Rasmus'un bebeği.
2. Mod_php yerine FastCGI . Mod_php genellikle en hızlı olduğu için bu konuda tartışma var. Ancak, dinamik PHP içeriği ve statik varlıkları (JS, CSS, flash, görüntüler, PDF'ler, vb.) Teslim tek bir Apache sunucunuz olduğunu varsayalım. Bu statik varlıklara yönelik isteklerin çok fazla bellek tüketmesi gerekmez, ancak PHP bir modül olduğu için her Apache iş parçacığındadır.

Apache için:

1. Çalışan MPM kullanın
2. KeepAlive'yi etkinleştir

Apache'den Lighttpd veya Nginx'e geçiş yapmayı düşünebilirsiniz . Apache'yi seviyorum. Aptalın birçok gelişmiş özelliğini kullanıyorum. Onun yükünü kabul ediyorum çünkü sunduklarına ihtiyacım var. Ortak LAMP yığını için gerekenden fazla ve kaynak israfı vardır.

MySQL için:

1. Optimizasyon çabalarınız, sorguları analiz etmek ve düzeltmek için harcadığımda, my.cnf değerlerinizi değiştirmek yerine 10 kat ödeyecektir. Önbelleğe almayı, bağlantılarınızı vb. Doğru yapmanın önemli olmadığını söylemiyorum ... ama çoğu insan için bu sorunun sadece% 9'u.
2. KG'niz sırasında, gönderilen tüm sorguları yakalamak için evreleme / dev mysqld adresinizdeki genel sorgu günlüğünü açın. (Bunu üretim mysql sunucunuzda YAPMAYIN!)
3. Sorguları analiz etmek için EXPLAIN kullanın . Özellikle ORM'li bir çerçeve kullanıyorsanız (DB'yi özetler ve sizi kendi SQL'inizi yazmanızı önlüyorsa), gereksiz JOIN'leri, WHERE yan tümcesi olmayan SEÇENEKLERİ, 'filesort kullanarak' tetikleyen ORDER BY'ları ve sorguları temizlemeniz gerekir. dizin kullanmayanlar.
4. MySQL 5.1 kullanıyorsanız , profil oluşturucudan yararlanın .

Dikkate değer diğer araçlar mk-visual-açıklamak

10 harika referans verdim. Bunlar seni mırıldanmalı. Lütfen bunun nasıl ortaya çıktığını bize bildirin.

PHP oturum dosyalarınızı bir tmpfs'ye taşıyın, APC (veya diğer) kullanın ve ihtiyacınız olmayan tüm PHP modüllerini kaldırın . İhtiyacınız olmayan / kullanmadığınız tüm Apache modüllerini kaldırın .

Bir tmpfs oluşturmak için (RAM'deki bir dizin!)

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

In / etc / fstab yeniden başlatma üzerinde oluşturmak için aşağıdaki satırı ekleyin!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

In /etc/apache2/php.ini RAM (tmpfs) içinde oturumları saklamak için ayarlayın!

session.save_handler = files
session.save_path = "/tmpfs"

Not: PHP dosyalarınız ve RAM'deki oturum dosyalarınız ile zar zor dokunursunuz!

Tarayıcıların çoğu şeyi önbelleğe alması için apache'de expires_module kullanın .

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

.Htaccess dosyalarını kullanmayın ! Bunun yerine, onları vhost config dosyasında sabit kodlayın! Tüm http istekleri başına disk kontrollerini büyük ölçüde ortadan kaldıracak / azaltacaktır ... gerçekten ekler.

Options FollowSymLinks 
AllowOverride None

Vhost.conf dosyanızda kullanılan .htaccess örneği ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

Aklıma birkaç şey geliyor.

Opcode önbellek her zaman iyi bir fikirdir. APC yerine http://eaccelerator.net/ adresini tercih ediyorum . APC ile birlikte eklemeye çalışmıyorsanız, neredeyse her zaman acı vericidir. Eaccelerator kadar fantezi olmasa da işe yarıyor gibi görünüyor.

Ters proxy de iyi bir fikirdir, ancak RAM kullanımını izlemeniz gerekir. Mpm-worker ile Apache 2.2'yi kendi başına yeterli miktarda RAM alabilmek için buluyorum. Senin durumunda Nginx gibi daha hafif bir şey tavsiye ve FASTCGI olarak PHP ile Apache çalıştırmak veya sadece işlem başına bırakın. Vernik, Kalamar, Nginx, vb. Kullanma fikri, statik içerik sunmalarını, kullanıcı bağlantılarıyla ilgilenmelerini ve yalnızca uygulama istekleri olarak değerlendirdiğiniz Apache'ye PHP isteklerini iletmelerini sağlamaktır.

Mysql 5.1'in oldukça yeni bir sürümünü çalıştırıyorsanız, en az 5.1.24 gibi, artık ikinci saniye yavaş günlüklerine erişebilirsiniz. 1 veya 2'de long_query_time'ı başlatacağım ve sonra gerçekten uzun olanları ele aldığınızda 0,5'e indirirdim. Mysql için internette çok sayıda genel ayar bilgisi var, ancak çok fazla yapacak RAM'iniz yok. Ayarlardan herhangi birini varsayılan olarak artırdınız mı? Çoğu varsayılan my.cnf dosyası yaklaşık 64 MB RAM kullanacak şekilde yapılandırılmıştır. En azından key_buffer'ı 16MB'den 64MB'a yükseltirdim.

Ayrıca Myisam veya Innodb tabloları mı kullanıyorsunuz? DB'de oturum tutuyorsanız, oturum tablosunu satır düzeyinde kilitleme yerine tablo düzeyinde kilitleme yapan bir Mysiam tablosu bırakmak yerine Innodb olarak değiştirmek (veya bunun yerine çerez yapmak) istersiniz. Temel olarak% 80'den fazla okumaya% 20'den fazla okuma yapan herhangi bir tablo, Innodb'a taşınmaya adaydır. Unutmayın, Myisam tabloları ile Innodb tabloları arasındaki RAM miktarını dengelemeniz gerekir, çünkü her biri için arabellekler ayrı yapılandırılır.

Ve son olarak başka bir 512MB RAM, kurulumunuzda uzun bir yol kat edecek, hatta daha ucuz veya kabaca aynı fiyat ise Mysql'i çalıştırmak için başka bir 512MB VPS bile. Aslında ikinci bir örneğe yaslanıyorum çünkü bu kullanılabilir disk IO'sunu iki katına çıkarır. VPS sunucularıyla ilgili sorunlardan biri, IO'nuzun aynı fiziksel sunucudaki diğer insanlardan korunmamasıdır.

Hmmm benim yazı tüm sorta dağınık, ama bakmak için çok yer verir. İyi şanslar.

• Apc gibi php için bir opcode önbellek kullanın.
• Kalamar veya vernik gibi bir http hızlandırıcı kullanın.

Düşük bellek durumunda (yüksek trafikli bir sunucu için 512Mb düşüktür), web sunucusu ve DB motoru seçiminizi dikkate almaya değer.

Lighttp kutunun dışında daha hafiftir, Apache genellikle çok fazla ayar yaptıktan sonra yapılabilir ve hatta bundan daha hafif seçenekler vardır. Elbette, bağımlı olduğunuz diğer sunucularda desteklenmeyen Apache özellikleri varsa bu mümkün değildir.

sqlite mySQL'den çok daha sıkı ve birçok koşulda daha hızlı. Kullandığınız motorun bunu destekleyip desteklemediğini ve bir deneme yapıp yapmadığını kontrol edin.

Diğer seçenek, kolay seçenek, eğer karşılayabiliyorsanız, VM'de daha fazla RAM elde etmektir.

Buradaki büyük önerilerin ötesinde, tüm VPS'lerin eşit yaratılmadığına dikkat edilmelidir. Deneyimlerime göre PHP CPU ağır oldu.

EC2'de nginx / apc / phpfpm / mysql (yerel) bir Wordpress AB Benchmark (ab-n 500 -c 25 http://domain.com/index.php ) giriş seviyesinde ~ 2 istek / saniye ile sonuçlandı "2GB "RAM / 1 İşlem Birimi Sunucusu".

Aynı Benchmark 512MB Rackspace Cloudserver üzerinde aynı komut yığınına karşı çalıştırılır (komut dosyası ile aynı işletim sistemine dağıtılır) ~ 80 req / saniye döndürür. Bu temel deneyde 4x Daha az koç, 40x performans.

AB sırasında zirveye baktığınızda, EC2'nin eşzamanlılığı kaldıramayacağını ve hemen% 100 CPU Yüküne çarpıp kilitleneceğini görüyorsunuz. Aynı ölçütte 512MB Sunucuda (sanallaştırılmış dört çekirdekli CPU) en üstte görüntülenen, Çekirdekler ~% 60 Yükü vuracak ve karşılaştırmayı sorunsuz bir şekilde ele alacaktır.

VPS'lerin üstlenilmesi ve herhangi bir taahhüt olmadan kapanması son derece kolaydır, VM / VPS'nizin bulunduğu altyapıyı test etmek zarar vermez!

DÜZENLEME 1: Ayrıca, EC2'nin "Yüksek CPU" Küçük Eşgörünümü yalnızca ~ 10 / req saniye verebildi, CPU hala darboğazdı. Sonuç olarak, EC2 ile stabilite / sağlamlık için performanstan ödün verdiğiniz ve elbette böyle bir ortam gerektiren birçok kullanım durumu var.