Saya punya server serba guna, menyediakan email, DNS, web, database, dan beberapa layanan lain untuk sejumlah pengguna.
Ada Xeon E3-1275 pada 3,40 GHz, 16 GB ECC RAM. Menjalankan Linux kernel 4.2.3, dengan ZFS-on-Linux 0.6.5.3.
Tata letak disk adalah 2x Seagate ST32000641AS drive 2 TB dan 1x Samsung 840 Pro 256 GB SSD
Saya memiliki 2 HD dalam mirror RAID-1, dan SSD bertindak sebagai perangkat cache dan log, semua dikelola dalam ZFS.
Ketika saya pertama kali mengatur sistem, itu sangat cepat. Tidak ada tolok ukur nyata, hanya ... cepat.
Sekarang, saya melihat perlambatan ekstrem, terutama pada sistem file yang menahan semua maildir. Melakukan pencadangan malam membutuhkan waktu lebih dari 90 menit hanya untuk surat berkapasitas 46 GB. Terkadang, cadangan menyebabkan beban ekstrem sehingga sistem hampir tidak responsif hingga 6 jam.
Saya telah menjalankan zpool iostat zroot
(kolam saya dinamai zroot
) selama perlambatan ini, dan terlihat menulis pada urutan 100-200kbytes / detik. Tidak ada kesalahan IO yang jelas, disk sepertinya tidak bekerja sangat keras, tetapi membaca hampir sangat lambat.
Yang aneh adalah bahwa saya memiliki pengalaman yang sama persis pada mesin yang berbeda, dengan perangkat keras spec yang sama, meskipun tanpa SSD, menjalankan FreeBSD. Itu bekerja dengan baik selama berbulan-bulan, kemudian menjadi lambat dengan cara yang sama.
Kecurigaan saya akan adalah ini: Saya menggunakan zfs-auto-snapshot untuk membuat snapshot bergulir dari setiap sistem file. Ini membuat 15 menit, setiap jam, setiap hari, dan snapshot bulanan, dan menyimpan sejumlah tertentu, menghapus yang tertua. Ini berarti bahwa seiring waktu, ribuan foto telah dibuat dan dihancurkan pada setiap sistem file. Ini adalah satu-satunya operasi tingkat sistem file yang sedang berlangsung yang dapat saya pikirkan dengan efek kumulatif. Saya telah mencoba menghancurkan semua snapshot (tetapi tetap menjalankan proses, membuat yang baru), dan tidak melihat adanya perubahan.
Apakah ada masalah dengan terus-menerus membuat dan menghancurkan snapshot? Saya menemukan memiliki mereka alat yang sangat berharga, dan telah dituntun untuk percaya bahwa mereka (selain dari ruang disk) lebih atau kurang nol-biaya.
Apakah ada hal lain yang dapat menyebabkan masalah ini?
EDIT: output perintah
Output dari zpool list
:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
zroot 1.81T 282G 1.54T - 22% 15% 1.00x ONLINE -
Output dari zfs list
:
NAME USED AVAIL REFER MOUNTPOINT
zroot 282G 1.48T 3.55G /
zroot/abs 18.4M 1.48T 18.4M /var/abs
zroot/bkup 6.33G 1.48T 1.07G /bkup
zroot/home 126G 1.48T 121G /home
zroot/incoming 43.1G 1.48T 38.4G /incoming
zroot/mail 49.1G 1.48T 45.3G /mail
zroot/mailman 2.01G 1.48T 1.66G /var/lib/mailman
zroot/moin 180M 1.48T 113M /usr/share/moin
zroot/mysql 21.7G 1.48T 16.1G /var/lib/mysql
zroot/postgres 9.11G 1.48T 1.06G /var/lib/postgres
zroot/site 126M 1.48T 125M /site
zroot/var 17.6G 1.48T 2.97G legacy
Ini bukan sistem yang sangat sibuk, secara umum. Puncak pada grafik di bawah ini adalah cadangan malam:
Saya sudah berhasil menangkap sistem selama perlambatan (mulai sekitar 8 pagi ini). Beberapa operasi cukup responsif, tetapi rata-rata beban saat ini 145, dan zpool list
hanya hang. Grafik:
sumber
zpool list
danzfs list
.Jawaban:
Lihatlah arc_meta_used dan arc_meta_limit. Dengan banyak file kecil, Anda dapat mengisi cache meta data dalam ram sehingga harus melihat pada disk untuk info file dan dapat memperlambat dunia untuk merayapi.
Saya tidak yakin bagaimana melakukan ini di Linux, pengalaman saya ada di FreeBSD.
sumber