Bagaimana prestasi memori & cakera mempengaruhi pangkalan data MongoDB anda

Artikel ini pada asalnya diterbitkan di MongoDB. Terima kasih kepada rakan kongsi yang menyokong SitePoint sebagai yang mungkin.

Memahami hubungan antara pelbagai cache dalaman dan prestasi cakera dan bagaimana hubungan ini mempengaruhi pangkalan data dan prestasi aplikasi boleh mencabar. Kami menggunakan tanda aras YCSB untuk menukar set kerja (bilangan dokumen yang digunakan dalam ujian) dan prestasi cakera untuk menunjukkan hubungan mereka dengan lebih baik. Apabila mengkaji hasilnya, kami akan memperkenalkan beberapa mekanisme dalaman MongoDB untuk meningkatkan pemahaman corak penggunaan pangkalan data biasa.

mata utama

Memahami prestasi asas cakera adalah penting untuk memahami prestasi pangkalan data keseluruhan.
Waktu menunggu dan penggunaan cakera yang tinggi menunjukkan kesesakan cakera.
WiredTiger IO adalah rawak.
Pertanyaan untuk satu set replika tunggal adalah satu berulir dan berurutan.
Prestasi cakera berkait rapat dengan saiz set kerja.

abstrak

Pengaruh utama prestasi sistem keseluruhan adalah bagaimana set kerja berkaitan dengan saiz cache enjin penyimpanan (memori yang didedikasikan untuk menyimpan data) dan prestasi cakera (ia memberikan batasan fizikal pada seberapa cepat data diakses).

Menggunakan YCSB, kami meneroka interaksi antara prestasi cakera dan saiz cache, menunjukkan bagaimana kedua -dua faktor ini mempengaruhi prestasi. Walaupun ujian ini menggunakan YCSB, penanda aras sintetik tidak dapat mewakili beban kerja pengeluaran. Latensi dan nombor throughput yang diperoleh melalui kaedah ini tidak memetakan prestasi pengeluaran. Kami menggunakan MongoDB 3.4.10, YCSB 0.14, dan MongoDB 3.6.0 pemandu untuk ujian ini. YCSB dikonfigurasi dengan 16 benang dan beban kerja baca sahaja.

Kami menunjukkan bahawa meletakkan set kerja ke dalam memori menyediakan prestasi aplikasi yang optimum, dan seperti mana -mana pangkalan data, melebihi had ini memberi kesan negatif terhadap latensi dan keseluruhannya.

Memahami metrik cakera

Apabila mempertimbangkan prestasi cakera, terdapat empat petunjuk penting:

1. melalui cakera, atau bilangan permintaan yang didarab dengan saiz permintaan. Ini biasanya diukur dalam megabait sesaat. Rawak membaca dan menulis prestasi dalam julat 4KB yang terbaik mewakili beban kerja pangkalan data standard. Perhatikan bahawa banyak penyedia awan mengehadkan melalui cakera atau jalur lebar.
2. kelewatan cakera. Pada Linux, ini diwakili dengan menanti, iaitu, masa (dalam milisaat) yang dibuat dari permohonan hingga masa data ditulis atau dikembalikan kepada permohonan. Bagi SSD, kelewatan biasanya kurang daripada 3 milisaat. HDD biasanya lebih tinggi daripada 7 milisaat. Latensi tinggi bermakna cakera sukar untuk bersaing dengan beban kerja yang diberikan.
3. iops cakera (operasi input/output sesaat). Iostat melaporkan metrik ini sebagai TPS. Pembekal awan yang diberikan boleh menjamin sejumlah IOPS untuk pemacu yang diberikan. Jika anda mencapai ambang ini, apa -apa akses selanjutnya akan dihukum, mengakibatkan kesesakan cakera. PCIe high-end yang dilampirkan peranti NVME boleh menyediakan 1,500,000 IOPS, sementara cakera keras biasa hanya boleh menyokong 150 IOPS.
4. Penggunaan cakera. Dilaporkan oleh Util dalam Iostat. Linux mempunyai banyak beratur setiap peranti untuk berkhidmat IO. Penggunaan menunjukkan berapa peratusan beratur ini dalam masa yang tertentu. Walaupun nombor ini mungkin mengelirukan, ia adalah penunjuk yang baik untuk kesihatan cakera keseluruhan.

Prestasi cakera ujian

Walaupun penyedia awan boleh menyediakan ambang IOPS untuk jumlah dan cakera tertentu, dan pengeluar cakera menerbitkan angka prestasi yang dijangkakan, hasil sebenar pada sistem anda mungkin berbeza -beza. Melakukan ujian IO boleh sangat membantu jika terdapat masalah dengan prestasi cakera yang diperhatikan.

Kami biasanya menggunakan FIO (penguji io fleksibel) untuk ujian. Kami menguji pada 10GB data, ioengine adalah psync, dan julat bacaan antara 4KB dan 32KB. Walaupun tetapan FIO lalai tidak mewakili beban kerja berwayar, kami mendapati konfigurasi ini menjadi penghampiran yang baik bagi penggunaan cakera berwayar.

semua ujian diulang dalam tiga senario cakera:

Scene 1

Tetapan cakera lalai yang disediakan oleh AWS C5 IO1 100GB Volume. 5000 IOPS

• 1144 IOPS / 5025 Bacaan Fizikal / Kedua / 99.85% Penggunaan

Scene 2

Hadkan cakera kepada 600 IOPS dan memperkenalkan kelewatan 7 milisaat. Ini harus mencerminkan prestasi RAID10 SAN biasa dengan cakera keras

• 134 IOPS / 150 BACA FIZIKAL / SEC / 95.72% Penggunaan

Scene 3

Batas lagi cakera kepada 150 IOPS dengan latensi 7 milisaat. Ini harus mensimulasikan cakera keras berputar biasa.

• 34 IOPS / 150 BACA FIZIKAL / SEC / 98.2% Penggunaan

pertanyaan bagaimana untuk berkhidmat dari cakera?

Enjin Penyimpanan WiredTiger melaksanakan cache sendiri. Secara lalai, saiz cache berwayar adalah 50% memori sistem dikurangkan 1GB untuk membolehkan proses sistem lain, cache sistem fail, dan operasi mongoDB dalaman yang menggunakan memori tambahan (seperti indeks bangunan, melakukan penyortiran memori, hasil deduplikasi, skor teks,, Sertai pemprosesan dan pengagregatan) Tinggalkan ruang yang cukup. Untuk mengelakkan kemerosotan prestasi dari kepenuhan cache, apabila penggunaan melebihi 80%, WiredTiger secara automatik akan mula mengeluarkan data dari cache. Untuk ujian kami, ini bermakna saiz cache yang sah adalah (7634MB - 1024MB)*. 5*.8, atau 2644MB.

Semua pertanyaan di -cache oleh WiredTiger. Ini bermakna pertanyaan akan menyebabkan indeks dan dokumen dibaca ke dalam cache berwayar melalui cache sistem fail dan kemudian mengembalikan hasilnya. Langkau langkah ini jika data yang diminta sudah ada dalam cache.

WiredTiger menggunakan algoritma pemampatan snappy untuk menyimpan dokumen secara lalai. Sebarang data yang dibaca dari cache sistem fail dikurangkan sebelum disimpan dalam cache berwayar. Indeks dimampatkan secara lalai dengan awalan dan dimampatkan dalam kedua -dua cakera dan cache berwayar.

Cache sistem fail adalah struktur sistem operasi yang digunakan untuk menyimpan fail yang sering diakses dalam memori untuk akses yang lebih mudah. Linux sangat aktif dalam fail cache dan akan cuba menggunakan semua memori yang tersedia menggunakan cache sistem fail. Jika lebih banyak memori diperlukan, cache sistem fail diusir untuk memberikan lebih banyak memori untuk aplikasi tersebut.

Ini adalah graf animasi yang menunjukkan akses cakera ke koleksi YCSB yang dihasilkan oleh operasi baca 100 YCSB. Setiap operasi adalah carian tunggal _id untuk satu dokumen.

Sudut kiri atas mewakili bait pertama dalam fail koleksi WiredTiger. Kedudukan cakera ditingkatkan ke kanan dan mengelilingi. Setiap baris mewakili segmen 3.5MB fail Koleksi WiredTiger. Akses disusun dalam susunan kronologi dan diwakili oleh bingkai animasi. Akses diwakili oleh dataran merah dan hijau untuk menyerlahkan akses cakera semasa.

3.5 mb vs 4kb

di sini, kita melihat bahawa fail data koleksi kami dibaca ke dalam ingatan. Kerana data disimpan di dalam B-Tree, kita mungkin perlu mencari lokasi cakera dokumen (akses kecil) dengan mengakses satu atau lebih lokasi pada cakera sebelum kita dapat mencari dan membaca dokumen kami (akses yang lebih besar).

Ini menunjukkan corak akses biasa untuk pertanyaan MongoDB -dokumen tidak mungkin dekat antara satu sama lain pada cakera. Ini juga menunjukkan bahawa walaupun selepas memasukkan satu sama lain, dokumen tidak mungkin berada di lokasi cakera berterusan.

Enjin Penyimpanan WiredTiger direka untuk "Baca Penuh": Ia akan mengeluarkan permintaan baca untuk semua data yang diperlukan sekaligus. Ini membawa kami untuk mengesyorkan mengehadkan pembacaan cakera cakera untuk penyebaran berwayar kepada sifar, kerana akses berikutnya tidak mungkin mengambil kesempatan daripada data tambahan yang diambil oleh pembacaan terlebih dahulu.

set berfungsi sesuai untuk cache

Untuk ujian pertama kami, kami menetapkan kiraan rekod kepada 2 juta, menghasilkan jumlah saiz data dan indeks 2.43 GB, atau 92% cache.

di sini kita melihat prestasi kuat Scene 1 adalah 76,113 permintaan sesaat. Memeriksa statistik cache sistem fail, kami mendapati bahawa kadar hit cache berwayar adalah 100%, tiada akses, dan tiada bait yang dibaca ke dalam cache sistem fail, yang bermaksud tiada tambahan IO diperlukan sepanjang ujian.

Seperti yang dijangkakan, dalam senario 2 dan senario 3, mengubah prestasi cakera (menambah 7 milisaat latency dan mengehadkan IOPs kepada 600 atau 150) mempunyai kesan minimum ke atas throughput (69, 579.5 dan 70,252 operasi/saat).

Kelewatan tindak balas 99% untuk ketiga -tiga ujian kami adalah dari 0.40 hingga 0.44 milisaat.

Set kerja lebih besar daripada cache berwayar, tetapi ia masih sesuai untuk cache sistem fail

Cache sistem operasi moden sering diakses fail untuk prestasi baca yang lebih baik. Kerana fail sudah ada dalam ingatan, mengakses fail cache tidak akan menghasilkan bacaan fizikal. Statistik cache sistem fail yang dipaparkan oleh perintah perintah Linux percuma saiz cache sistem fail.

Apabila kami meningkatkan kiraan rekod dari 2 juta hingga 3 juta, kami meningkatkan jumlah saiz data dan indeks kepada 3.66GB, 38% lebih besar daripada yang dari perkhidmatan cache Wiredtiger sahaja.

Metrik dengan jelas menunjukkan bahawa kita membaca purata 548 Mbps ke dalam cache berwayar, tetapi ketika memeriksa metrik cache sistem fail, kita dapat melihat kadar hit sebanyak 99.9%.

Untuk ujian ini, kami mula melihat penurunan prestasi, dengan hanya 66,720 operasi yang dilakukan sesaat, penurunan 8% berbanding dengan garis dasar kami, sementara garis dasar kami hanya dari perkhidmatan cache berwayar.

Seperti yang dijangkakan, dalam kes ini, penurunan prestasi cakera tidak menjejaskan keseluruhan operasi kami (64,484 dan 64,229, masing -masing). Penalti untuk membaca dari cache sistem fail akan lebih jelas apabila dokumen lebih mudah untuk memampatkan atau jika CPU adalah faktor yang membatasi.

kami melihat kenaikan 54% dalam latensi p99 kepada .53 -.55 ms.

Set kerja sedikit lebih besar daripada cache sistem WiredTiger dan fail

kami telah menentukan bahawa cache sistem WiredTiger dan fail berfungsi bersama -sama untuk menyediakan data untuk menyampaikan pertanyaan kami. Walau bagaimanapun, apabila kita meningkatkan kiraan rekod dari 3 juta hingga 4 juta, kita tidak boleh lagi memanfaatkan cache ini untuk menyampaikan pertanyaan. Saiz data kami meningkat kepada 4.8GB, 82% lebih besar daripada cache wiredtiger kami.

di sini, kita membaca ke dalam cache WiredTiger pada 257.4 Mbps. Kadar hit cache sistem fail kami dikurangkan kepada 93-96%, yang bermaksud 4-7% bacaan membawa kepada bacaan fizikal dari cakera.

Mengubah latency IOPS dan cakera yang ada mempunyai kesan besar terhadap prestasi ujian ini.

Kelewatan tindak balas persentil ke -99 meningkat lagi. Adegan 1:19 Milliseconds, Scene 2: 171 Milliseconds, Scene 3: 770 Milliseconds, yang 43 kali, 389 kali dan 1751 kali berbanding dengan keadaan dalam cache.

Berbanding dengan ujian terdahulu kami yang penuh dengan caching-mesra, kami melihat pengurangan prestasi 75% apabila MongoDB menawarkan 5000 IOP penuh. Senario 2 dan Senario 3 mencapai 5139.5 dan 737.95 operasi sesaat, masing -masing, membuktikan kesesakan IO.

set kerja jauh lebih besar daripada cache sistem wiredtiger dan fail

Bergerak ke 5 juta rekod, kami meningkatkan saiz data dan indeks kepada 6.09GB, yang lebih besar daripada cache sistem WiredTiger dan File kami. Kami melihat throughput kami di bawah IOPS kami. Dalam kes ini, kami masih melayani 81% daripada WiredTiger yang dibaca dari cache sistem fail, tetapi bacaan dari limpahan cakera menepuk IO kami. Kami melihat kelajuan bacaan cache sistem fail untuk ujian ini adalah 71, 8.3 dan 1.9 Mbps.

Kelewatan tindak balas persentil ke -99 meningkat lagi. Senario 1: 22ms, Senario 2: 199ms, Senario 3: 810ms, yang 52 kali, 454 kali dan 1841 kali berbanding dengan latensi tindak balas dalam cache. Di sini, menukar cakera IOPs memberi kesan yang ketara kepada kami.

abstrak

Melalui siri ujian ini, kami membuktikan dua mata utama.

Jika set kerja sesuai untuk caching, prestasi cakera tidak banyak mempengaruhi prestasi aplikasi.

1. Prestasi cakera dengan cepat menjadi faktor yang membatasi dalam throughput apabila set kerja melebihi memori yang tersedia.
Memahami bagaimana MongoDB memanfaatkan memori dan cakera adalah bahagian penting dalam menyesuaikan saiz penempatan dan pemahaman prestasi. Kerja dalaman enjin penyimpanan berwayar cuba untuk memanfaatkan perkakasan, tetapi memori dan cakera adalah dua bahagian infrastruktur kritikal yang mempengaruhi ciri -ciri prestasi keseluruhan beban kerja.

soalan yang sering ditanya mengenai prestasi memori dan cakera di MongoDB

Bagaimanakah MongoDB menggunakan ruang memori dan cakera?

MongoDB menggunakan ruang memori dan cakera untuk menyimpan dan menguruskan data. Ia menggunakan sistem fail dipetakan memori untuk penyimpanan data, yang bermaksud ia memetakan keseluruhan fail data ke dalam RAM. Ini membolehkan MongoDB untuk memproses dataset yang besar. Butiran pengurusan subsistem memori maya sistem operasi, pertukaran data ke dalam dan keluar dari ingatan yang diperlukan. Sebaliknya, ruang cakera digunakan untuk menyimpan fail data, indeks, dan log. MongoDB secara automatik memperuntukkan ruang cakera dalam ketulan besar untuk mengoptimumkan operasi menulis.

Apakah kesan penggunaan cakera tinggi I/O di MongoDB?

Penggunaan cakera tinggi I/O akan menjejaskan prestasi pangkalan data MongoDB. Ia menyebabkan operasi membaca dan menulis yang lebih perlahan, yang dapat mengurangkan prestasi keseluruhan aplikasi. Ini amat bermasalah untuk aplikasi yang memerlukan akses data masa nyata. Penggunaan cakera tinggi I/O juga boleh menyebabkan peningkatan penggunaan CPU, kerana sistem menghabiskan lebih banyak masa menguruskan operasi cakera.

Bagaimana untuk memantau penggunaan ruang cakera di MongoDB?

MongoDB menyediakan beberapa alat untuk memantau penggunaan ruang cakera. Perintah DB.Stats () menyediakan gambaran keseluruhan peringkat pangkalan data, termasuk jumlah saiz fail dan indeks data. Perintah db.collection.stats () menyediakan maklumat yang lebih terperinci mengenai koleksi tertentu, termasuk saiz data dan indeks. Di samping itu, MongoDB Atlas (produk pangkalan data-sebagai-perkhidmatan yang disediakan oleh MongoDB) menyediakan satu set alat pemantauan yang komprehensif, termasuk makluman mengenai penggunaan ruang cakera yang tinggi.

Bagaimana menyelesaikan penggunaan ruang cakera yang tinggi di MongoDB?

Terdapat beberapa strategi untuk menangani penggunaan ruang cakera yang tinggi di MongoDB. Salah satu cara ialah memadam data atau koleksi yang tidak perlu. Pendekatan lain adalah menggunakan arahan padat, yang menafikan fail data dan mengitar semula ruang cakera yang tidak digunakan. Walau bagaimanapun, arahan ini memerlukan banyak ruang cakera percuma dan boleh menjejaskan prestasi pangkalan data. Sharding (mengedarkan data ke pelbagai pelayan) juga boleh membantu menguruskan penggunaan ruang cakera.

Apakah pemacu RAM dan bagaimana ia berkaitan dengan MongoDB?

Pemacu RAM adalah sekeping memori yang dianggap oleh sistem operasi sebagai pemacu cakera. Kerana RAM jauh lebih cepat daripada penyimpanan cakera, menggunakan pemacu RAM dapat meningkatkan prestasi aplikasi yang memerlukan akses data berkelajuan tinggi. Walau bagaimanapun, kerana RAM tidak menentu, data yang disimpan dalam pemacu RAM hilang apabila sistem dimulakan semula. Dalam konteks MongoDB, pemacu RAM boleh digunakan untuk menyimpan data atau indeks yang sering diakses untuk prestasi yang lebih baik. Walau bagaimanapun, ini perlu dilakukan dengan berhati -hati, kerana kehilangan data mungkin berlaku jika sistem dimulakan semula.

Bagaimana MongoDB Mengendalikan Pengurusan Memori?

MongoDB bergantung kepada sistem operasi asas untuk pengurusan memori. Ia menggunakan sistem fail yang dipetakan memori, yang membolehkan subsistem memori maya sistem operasi untuk menguruskan butiran data dalam memori serta data pada cakera. Pendekatan ini membolehkan MongoDB untuk memproses dataset yang besar, tetapi ia juga bermakna penggunaan memori MongoDB mungkin dipengaruhi oleh proses lain yang berjalan pada sistem yang sama.

Bagaimana untuk mengoptimumkan penggunaan memori MongoDB?

Terdapat beberapa strategi untuk mengoptimumkan penggunaan memori MongoDB. Salah satu cara ialah memastikan set kerja anda sesuai untuk ingatan. Set kerja sering diakses bahagian data. Jika set kerja anda sesuai untuk ingatan, MongoDB boleh mengelakkan operasi I/O cakera yang mahal. Pendekatan lain ialah menggunakan indeks dengan cekap. Indeks dapat meningkatkan prestasi pertanyaan dengan ketara, tetapi mereka juga boleh memori. Oleh itu, adalah penting untuk mewujudkan indeks dengan bijak dan memantau kesannya terhadap penggunaan memori.

Bagaimanakah MongoDB mengendalikan operasi cakera I/O?

MongoDB menggunakan log menulis-log untuk memastikan integriti data. Mereka pertama kali ditulis kepada log sebelum sebarang perubahan dibuat ke fail data. Ini membolehkan MongoDB pulih dari kemalangan atau kegagalan kuasa. Walau bagaimanapun, pembalakan juga boleh meningkatkan operasi I/O cakera, yang boleh menjejaskan prestasi. Oleh itu, adalah penting untuk memantau penggunaan I/O cakera dan mengambil langkah untuk mengoptimumkannya jika perlu.

Bagaimana untuk mengoptimumkan operasi I/O cakera MongoDB?

Terdapat beberapa strategi untuk mengoptimumkan operasi I/O cakera MongoDB. Salah satu cara ialah menggunakan SSD, yang boleh mengendalikan lebih banyak IOPs daripada pemacu keras tradisional. Pendekatan lain ialah menggunakan konfigurasi RAID yang dioptimumkan untuk operasi menulis. Di samping itu, anda boleh menyesuaikan tetapan pembalakan MongoDB untuk mengurangkan kesan pada cakera I/O. Walau bagaimanapun, ini perlu dilakukan dengan berhati -hati, kerana ia boleh menjejaskan integriti data.

Bagaimanakah prestasi memori dan cakera mempengaruhi prestasi keseluruhan pangkalan data MongoDB?

Memori dan prestasi cakera adalah faktor utama dalam prestasi keseluruhan pangkalan data MongoDB. Jika set kerja anda sesuai untuk ingatan, MongoDB boleh mengelakkan operasi I/O cakera yang mahal, yang dapat meningkatkan prestasi dengan ketara. Begitu juga, operasi cakera I/O yang berkesan dapat meningkatkan prestasi operasi menulis dan memastikan integriti data. Oleh itu, adalah penting untuk memantau dan mengoptimumkan prestasi memori dan cakera untuk memastikan prestasi terbaik pangkalan data MongoDB.

Atas ialah kandungan terperinci Bagaimana prestasi memori & cakera mempengaruhi pangkalan data MongoDB anda. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!