I / O disk tinggi ketika cache digunakan?


9

Beberapa hari yang lalu saya melihat disk I / O menunggu dan aktivitas drop (yang hebat). Kemudian saya juga melihat bahwa cache saya penuh (*) dan terfragmentasi. Lalu saya membersihkan cache. Setelah itu, latensi disk dan aktivitas disk melonjak ke level sebelumnya (yang buruk).

IOtop menunjukkan bahwa [jbd2 / sda2-8] dan [flush-8:00] selalu di atas penggunaan disk. Ini adalah Dell R210, perangkat keras RAID 1 (H200) dengan banyak memori bebas (total 16 GB, yang sekitar 8 GB adalah buffer / cache).

(*) Cache adalah cache opcode APC untuk PHP, yang mengurangi akses disk untuk eksekusi skrip PHP. Cache penuh dan terfragmentasi karena menyertakan file dari instance pengembangan. Ketika saya perhatikan itu, saya memfilternya.

Pertanyaannya adalah: mengapa disk I / O meningkat ketika secara teori seharusnya menurun? Di bawah ini adalah beberapa grafik dari munin. Cache penuh mulai 6 hingga 8 Februari.

masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini Cache APC saat ini ok.

Ubah setelah saya berkomentar apc.mmap_file_mask seperti yang diceritakan oleh @ cyberx86

masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini

Dan setelah beberapa hari https://serverfault.com/a/362152/88934


2
Grafik itu tidak menunjukkan peningkatan IO.
psusi

1
Jika Anda menggunakan pemetaan memori yang didukung file (mis. apc.mmap_file_mask=/tmp/apc.XXXXXX) Anda mungkin melihat I / O yang lebih tinggi. Coba pengaturan apc.mmap_file_maskuntuk menggunakan memori bersama (mis. /apc.shm.XXXXXX) Atau ke /dev/zero(memori mmapped anonim).
cyberx86

1
@psusi dari 6 Februari 12 siang sampai 8 Februari 12 siang rendah, lalu meningkat.
jcisio

@ cyberx86 Saya baru saja mengubahnya (berkomentar di baris itu untuk menggunakan memori mmapped anonim) dan sepertinya itu membantu. Saya akan memantau beberapa menit lagi untuk melihatnya. Terima kasih.
jcisio

2
@psusi Ada beberapa masalah yang hanya bisa saya lanjutkan, tidak menjelaskan: 1 / cache APC hilang (tetapi cache OS hit untuk file-file PHP, jadi sangat sedikit disk I / O, lebih sedikit waktu menunggu tetapi lebih banyak waktu I / O rata-rata , yang sebagian besar transaksi MySQL InnoDB melakukan) 2 / cache APC hit tetapi APC menggunakan file (kemudian OS cache ketinggalan, tidak tahu mengapa) 3 / singkat, pertanyaan saya adalah "ketika cache bekerja dengan buruk, (hampir) tidak ada disk I / O "- apa yang Anda katakan sepenuhnya bertentangan dengan itu.
jcisio

Jawaban:


10

Jika Anda menggunakan pemetaan memori yang didukung file (mis. apc.mmap_file_mask=/tmp/apc.XXXXXX) Anda mungkin melihat I / O yang lebih tinggi.

Coba pengaturan apc.mmap_file_maskuntuk menggunakan memori bersama (mis. /apc.shm.XXXXXX) Atau ke /dev/zero(memori mmapped anonim). Menjaga pengaturan tidak terdefinisi default untuk menggunakan memori mmapped anonim.

Biasanya, file yang mmapped adalah hal yang hebat:

  • Dibandingkan dengan menyimpan sesuatu sepenuhnya dalam memori, file yang mmapped biasanya membutuhkan lebih sedikit memori
  • Dibandingkan menyimpan sesuatu ke file, file yang mmapped membutuhkan lebih sedikit disk I / O (karena write dapat digabungkan bersama-sama).

Namun, dibandingkan dengan menyimpan sesuatu yang murni di memori, mereka dikenakan tambahan I / O - jadi ketika file terus berubah. Kelemahan dari tidak menggunakan file mmapped adalah kurangnya persistensi - cache Anda tidak akan selamat dari restart, karena disimpan hanya dalam memori.

Orang mungkin menyarankan karena itu, bahwa sementara cache sedang mengisi dan menstabilkan, itu mengalami perubahan paling besar, yang harus terus-menerus ditulis ke disk; begitu cache penuh, ttl untuk setiap objek memperlambat laju data di cache dibalik, mengurangi perubahan dan mengurangi penulisan disk.


4

Setelah beberapa hari, sekarang saya ingin kembali dengan beberapa grafik. Perubahan meningkatkan banyak situasi itu. Ini mengurangi segalanya, kecuali waktu layanan IO (saya pikir itu karena tidak ada lagi file PHP kecil sepele yang murah).

masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini masukkan deskripsi gambar di sini

Server memuat (sudah cukup rendah, jadi saya belum menemukan perubahannya).

masukkan deskripsi gambar di sini


Bisakah Anda memberikan perubahan yang Anda buat?
Mircea Vutcovici

Baca komentar pertanyaan dan jawaban yang diterima. Saya berkomentarapc.mmap_file_mask=/tmp/apc.XXXXXX
jcisio

Hei, maaf mengganggumu. Apakah Anda pernah melihat efek samping mengomentari baris mmap_file_mask ?. Saya melihat masalah yang sama ... dan ini jelas memecahkan masalah penggunaan I / O saya. Tapi saya bertanya-tanya ... apakah tidak ada lagi yang akan rusak !. Terima kasih!
Jorge Leandro Perez

Saya tidak punya masalah mengomentari kalimat itu.
jcisio
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.