Saya menjalankan aplikasi facebook yang saat ini memiliki 300 - 600 pengguna secara bersamaan (dan terus bertambah). Untuk menyiapkan perangkat keras yang sedang tumbuh, saya mengubah ram i7 / 12gb / 2x 80 GB intel x25 ssd (debian 5.0 / mysql 5.0 / 64bit) menjadi bi-xeon / 24gb ram / 2x 120GB intel 320 ssd (ubuntu 10.10 / mysql 5.1 / 64bit).
sekarang saya menghadapi masalah bahwa kinerjanya lebih buruk daripada di "kotak kecil". Di kedua server saya sudah menggunakan nginx / php fcgi untuk menyajikan konten.
Saya hanya menggunakan innodb, memiliki Baca / Tulis sekitar 65% / 35%. Sekitar 800 - 1000 qps tetapi semua Pertanyaan sederhana dan tidak pernah bergabung dengan lebih dari 1 tabel tambahan. Semua indeks ditetapkan dan tidak ada kueri individual yang dicatat dalam log lambat (> 2d). Saat ini saya memiliki sekitar 400mb data (sekitar 1gb dengan indeks) mengharapkannya dua kali lipat setiap bulan.
Saya akan mengagumi semua orang yang bisa memberi saya petunjuk apa yang harus diubah untuk membuatnya berjalan lebih lancar.
Konfigurasi lama pada kotak i7 seperti ini (mixed myisam / innodb), berkinerja cukup baik hingga 800+ pengguna.
my.cnf tua
key_buffer = 3000M
max_allowed_packet = 128M
thread_stack = 192K
thread_cache_size = 8
max_connections = 400
table_cache = 8000
thread_concurrency = 16
query_cache_limit = 8M
query_cache_size = 128M
wait_timeout = 10
interactive_timeout = 10
connect_timeout = 600
low_priority_updates = 1
join_buffer_size = 8M
read_buffer_size = 2M
sort_buffer_size = 3M
myisam_sort_buffer_size = 32M
read_rnd_buffer_size = 4M
innodb_buffer_pool_size = 3G
innodb_log_buffer_size = 8M
Konfigurasi baru pada kotak bi-xeon seperti ini (innodb murni), menyebabkan beban tinggi dengan 300+ pengguna. Sekitar 30 proses mysql duduk di bagian atas daftar proses.
Disk I / O:
avg-cpu: %user %nice %system %iowait %steal %idle
36.28 0.00 1.60 0.17 0.00 61.95
my.cnf
key_buffer = 64M
max_allowed_packet = 1M
thread_stack = 192K
thread_cache_size = 128
max_connections = 500
table_cache = 512
#thread_concurrency = 10
sort_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
tmp_table_size = 32M
max_heap_table_size = 32M
query_cache_limit = 1M
query_cache_size = 128M
query_cache_type = 1
innodb_file_per_table = 1
innodb_data_file_path = ibdata1:1000M:autoextend
innodb_buffer_pool_size = 16384M
innodb_additional_mem_pool_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_support_xa = 0
innodb_lock_wait_timeout = 50
innodb_flush_method=O_DIRECT
innodb_log_files_in_group = 2
innodb_log_file_size = 128M
innodb_log_buffer_size = 8M
innodb_thread_concurrency = 12
sumber
skip-name-resolve
dinonaktifkan dan bisakah diaktifkan?Jawaban:
Saya telah menulis beberapa posting di StackExchnage
Silakan baca ini untuk panduan yang Anda butuhkan.
Sekarang, untuk masalah yang lebih mendesak: Anda menyebutkan bahwa Anda memiliki 400MB data, 1GB dengan indeks. Semacam itu membuat saya takut bahwa indeks Anda 50% lebih besar dari data. Namun, karena semua data Anda adalah InnoDB dan Anda puas dengan kinerja permintaan saat ini, pengaturan Anda lebih dari cukup, terutama innodb_buffer_pool_size 16384MB. Itu 16GB. Anda sudah siap di sana. Tapi tunggu !!! Innodb_log_file_size Anda adalah 128 juta? Terlalu kecil mengingat kolam penyangga 16GB. Anda harus mengubah ukuran file ib_logfile (atur innodb_log_file_size ke 2047M).
Anda mungkin mengalami pemuatan berdasarkan per-utas. Coba atur buffer koneksi Anda (join_buffer_size, sort_buffer_size, read_buffer_size, read_rnd_buffer_size)
From Me: Mengapa MySQL mengatakan saya kehabisan memori?
Dari @DTest: Bagaimana Anda menghitung variabel mysql max_connections?
Cobalah !!!
sumber
Jika demikian, periksa untuk peningkatan / penurunan kinerja halus di http://mysql.rjweb.org/doc.php/myisam2innodb
innodb_flush_log_at_trx_commit = 1
- menyebabkan penulisan ke log setelah setiap transaksi. Pertimbangkan untuk menggunakan
= 2
.max_connections
-SHOW GLOBAL STATUS LIKE 'max_used_connections'
- yang akan memberi tahu Anda berapa banyak yang Anda butuhkan sejak startup.
cache permintaan:
Ini mungkin menyakitkan. Di atas, katakanlah,
50M
QC menghabiskan terlalu banyak waktu untuk perawatan. Memiliki ituON
mungkin sia-sia juga. LakukanSHOW GLOBAL STATUS LIKE 'Qc%'
untuk memeriksa efektivitas.sumber