Penalaan NVMe pada pelayan Linux: panduan pengoptimuman lengkap

Jika anda bekerja dengan pelayan Linux dan telah bertukar kepada pemacu NVMe, anda mungkin perasan bahawa, walaupun ia jauh lebih pantas daripada HDD atau pun SSD SATAAnda tidak selalu melihat angka menakjubkan yang dijanjikan dalam helaian spesifikasi semasa pengeluaran. Bukannya perkakasan telah mengecewakan anda: biasanya sistem pengendalian, konfigurasi kernel dan perkhidmatan yang menghalang anda.

Dalam artikel ini kita akan melihat cara untuk melaksanakan penalaan NVMe yang serius pada pelayan LinuxKami akan mempertimbangkan prestasi tulen (latency, IOPS dan lebar jalur) dan memacu ketahanan. Tambahan pula, kami akan mengintegrasikannya dengan lapisan pangkalan data (MySQL/MariaDB, terutamanya InnoDB) dan dengan amalan terbaik untuk penggunaan SSD dan NVMe bagi memastikan platform anda berfungsi secara optimum. Matlamatnya adalah untuk anda beralih dengan lancar daripada ujian makmal dengan Fio kepada beban kerja pengeluaran dunia sebenar yang benar-benar hebat.

Prasyarat dan alatan untuk mengoptimumkan NVMe pada Linux

Sebelum mula mengubah parameter, adalah penting untuk mempunyai akses akar ke pelayan dan pelan sandaran yang baikBanyak tetapan yang akan kita bincangkan mempengaruhi kernel, pembahagian atau format peranti, jadi sebarang kesilapan boleh menyebabkan perkhidmatan ranap atau volum menjadi tidak dapat dipulihkan.

Anda juga perlu mempunyai utiliti tertentu untuk mengurus NVMe, memantau I/O dan penanda arasPada Debian atau Ubuntu, anda boleh memasangnya dengan:

Pemasangan pada Debian/Ubuntu: sudo apt update
sudo apt install nvme-cli fio util-linux iotop sysstat numactl -y

Dalam sistem berasaskan RHEL (Rocky, Alma, CentOS, dll.) ia dicapai dengan:

Pemasangan dalam RHEL dan derivatif: sudo dnf update -y
sudo dnf install nvme-cli fio util-linux iotop sysstat numactl -y

Dengan alat-alat ini, anda akan dapat kenal pasti peranti NVMe anda, periksa kesihatannya dan kemas kini perisian tegar pada Linux, ukur latensi dan daya pemprosesan secara objektif dan berulang, sesuatu yang kritikal sebelum menyentuh apa-apa untuk dapat membandingkan "sebelum" dan "selepas".

Temui, kenal pasti dan ukur peranti NVMe anda

Langkah pertama ialah menyenaraikan pemacu NVMe yang sebenarnya anda miliki dan spesifikasinya. Anda boleh melihatnya dengan sangat jelas dengan nvme-cli dan tanpa perlu bersusah payah dengan nama-nama pelik dalam /dev.

Senaraikan peranti NVMe: nvme list

Jika anda ingin pergi lebih jauh, arahan berikut menunjukkan Keupayaan pengawal NVMe (barisan arahan, saiz pemindahan maksimum, dsb.):

Butiran pengawal NVMe: nvme id-ctrl -H /dev/nvme0

Dan untuk melihat maklumat tentang "ruang nama" (format LBA, saiz sektor dan kedudukan prestasi relatif):

Butiran ruang nama NVMe: nvme id-ns -H /dev/nvme0n1

Sebelum anda mula memperhalusi sistem, adalah idea yang baik untuk menyimpan Garis asas prestasi dengan fioContohnya, anda boleh mengukur kependaman dalam bacaan 4K rawak dengan I/O langsung:

Penanda aras asas (fio randread 4K): fio --name=randread --filename=/dev/nvme0n1 --rw=randread --bs=4k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Dan daya pemprosesan bacaan berjujukan pada 128K:

Penanda aras asas (fio seqread 128K): fio --name=seqread --filename=/dev/nvme0n1 --rw=read --bs=128k \
--iodepth=64 --numjobs=1 --ioengine=io_uring --direct=1 --time_based=1 --runtime=20

Untuk memahami bagaimana sistem secara keseluruhannya berfungsi, adalah berguna untuk menambahnya dengan iostat dan log pintar:

semakan iostat / log pintar: iostat -x 2 10
nvme smart-log /dev/nvme0

Dengan cara ini anda akan tahu sama ada kesesakan anda sedang berlaku masa perkhidmatan giliran, suhu, ralat media atau hanya di lapisan atas (sistem fail, pangkalan data, dll.).

Pengurusan Kuasa NVMe (APST) untuk latensi rendah

Pemacu NVMe dilaksanakan APST (Peralihan Keadaan Kuasa Autonomi)satu mekanisme untuk menjimatkan tenaga dengan memasuki keadaan kuasa rendah yang lebih dalam. Itu bagus untuk komputer ribaTetapi pada pelayan yang mempunyai giliran milisaat atau mikrosaat penting, "bangun" SSD tersebut boleh menyebabkan lonjakan latensi yang tidak menyenangkan.

Jika anda mengutamakan latensi konsisten pada penjimatan tenagaAnda boleh melumpuhkan APST dengan melaraskan parameter modul nvme_core (lihat berita kernel). Pada sistem dengan GRUB, sudah memadai untuk menambah:

Lumpuhkan APST (GRUB): sudo sed -i 's/GRUB_CMDLINE_LINUX="/GRUB_CMDLINE_LINUX="nvme_core.default_ps_max_latency_us=0 /' /etc/default/grub
sudo update-grub

Selepas dimulakan semula, kernel akan berhenti menghantar pemacu ke keadaan penjimatan kuasa yang mendalam dan, secara amnya, Barisan latensi 99% dan 99.9% sepatutnya bertambah baikdengan syarat penyejukan pelayan mencukupi untuk peningkatan suhu.

Penjadual I/O sesuai untuk tetapan NVMe dan lapisan blok

Penjadual I/O ialah lapisan yang menentukan Dalam susunan apakah permintaan baca dan tulis dilayan? ke arah peranti tersebut. Dengan pemacu mekanikal, adalah sangat masuk akal untuk menggunakan penjadual kompleks yang mengoptimumkan pergerakan fizikal kepala, tetapi dengan NVMe itu tidak perlu dan bahkan boleh menjadi penghalang.

Dalam kebanyakan pengedaran moden, pemacu NVMe sudah pun menggunakan penjadual «tiada» (atau mq-tarikh akhir dalam kes tertentu)Walaupun begitu, ia patut diperiksa:

Sahkan penjadual I/O: cat /sys/block/nvme0n1/queue/scheduler

Jika anda melihat sesuatu yang berbeza dan beban kerja anda terutamanya adalah I/O rawak latensi rendah, anda boleh memaksa penjadual kepada "tiada":

Paksa penjadual 'tiada': echo none | sudo tee /sys/block/nvme0n1/queue/scheduler

Untuk beban kerja yang sangat bercampur dengan operasi penulisan intensif, "mq-deadline" boleh menyediakan keseimbangan yang lebih baik antara daya pemprosesan dan kependaman:

Paksa penjadual 'mq-deadline': echo mq-deadline | sudo tee /sys/block/nvme0n1/queue/scheduler

Selain penjadual, lapisan blok menawarkan dua kawalan penting lain: saiz permintaan maksimum dan bacaan awalBacaan awal (read_ahead_kb) "membaca lebih awal" lebih banyak data daripada yang diminta, yang berguna dalam akses berjujukan yang panjang tetapi tidak produktif dalam akses rawak.

Nilai kb baca_awal_biasa: echo 128 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # cargas aleatorias (BBDD)
echo 4096 | sudo tee /sys/block/nvme0n1/queue/read_ahead_kb # secuencial grande (backups, vídeo, etc.)

Mengenai saiz permintaan maksimum (max_sectors_kb)Adalah dinasihatkan untuk menyelaraskannya dengan saiz I/O optimum unit dan tidak melebihi perkakasan maksimum:

Rujuk saiz I/O optimum: cat /sys/block/nvme0n1/queue/optimal_io_size
cat /sys/block/nvme0n1/queue/max_hw_sectors_kb

Sebaik sahaja anda mengetahui perkara ini, anda boleh menetapkan nilai yang munasabah, contohnya 1024 KB:

Tetapkan max_sectors_kb: sudo sh -c 'echo 1024 > /sys/block/nvme0n1/queue/max_sectors_kb'

Penalaan halus CPU dan afiniti NUMA untuk NVMe

Dalam pelayan moden dengan berbilang CPU atau soket (NUMA), Latensi akses memori dan peranti tidak seragamPemacu NVMe secara fizikalnya hampir dengan nod NUMA tertentu, dan jika thread yang menggunakannya berada pada nod lain, setiap I/O melintasi bas antara soket dengan tol latensi yang terhasil.

Itulah sebabnya penting untuk memahami kedua-dua gangguan NVMe dan proses yang menggunakannya. dilampirkan pada nod NUMA yang samaPertama, ketahui IRQ yang digunakan oleh pemacu NVMe:

Cari IRQ NVMe: grep -i nvme /proc/interrupts

Kemudian anda boleh menetapkan, sebagai contoh, semua IRQ dari nvme0 ke teras 0-3:

Tetapkan afiniti IRQ kepada nukleus: for i in $(grep -i nvme0 /proc/interrupts | awk -F: '{print $1}'); do
echo 0-3 | sudo tee /proc/irq/$i/smp_affinity_list
done

Apabila anda melancarkan pangkalan data atau perkhidmatan utama anda, walaupun dalam virtualisasi dengan KVM, menggunakan numactl untuk membetulkan CPU dan memori ke nod yang sama:

Jalankan perkhidmatan dengan numactl: numactl --cpunodebind=0 --membind=0 tu-binario --tus-opciones

Satu lagi pelarasan kecil pada lapisan blok ialah rq_affinityIni menunjukkan bagaimana giliran penyiapan I/O diproses. Nilai 2 memaksa penyiapan dikendalikan pada teras yang sama yang mengeluarkan permintaan, sekali gus meningkatkan lokaliti cache.

Aktifkan rq_affinity=2: echo 2 | sudo tee /sys/block/nvme0n1/queue/rq_affinity

Pastikan perubahan penalaan NVMe berterusan dengan udev

Semua perubahan yang dibuat dengan menyentuh fail dalam /sys Mereka hilang semasa memulakan semulaUntuk mengelakkan daripada menjalankan skrip secara manual setiap kali, pendekatan paling bersih adalah dengan menggunakan peraturan udev yang menggunakan penalaan sebaik sahaja kernel mengesan peranti.

Contohnya, untuk menetapkan penjadual kepada tiada, rq_affinity kepada 2, dan read_ahead kepada 128 KB pada semua pemacu NVMe, anda boleh mencipta:

Cipta peraturan udev untuk penalaan: sudo nano /etc/udev/rules.d/60-nvme-tuning.rules

Dengan kandungannya:

Contoh peraturan udev: ACTION=="add|change", KERNEL=="nvme*n*", \
ATTR{queue/rq_affinity}="2", \
ATTR{queue/scheduler}="none", \
ATTR{queue/read_ahead_kb}="128"

Kemudian anda muat semula udev dan mencetuskan peraturan:

Gunakan peraturan udev: sudo udevadm control --reload
sudo udevadm trigger

Jika anda juga ingin memastikan semua unit yang dipasang mendapat manfaat daripada Pilihan seperti noatime atau tmpfs untuk direktori sementaraGabungkan peraturan ini dengan konfigurasi /etc/fstab yang baik, yang juga mengurangkan penulisan dan membantu jangka hayat SSD dan NVMe.

Penjajaran partition, sektor logik dan TRIM pada NVMe

Agar pemacu NVMe berfungsi sebagaimana mestinya dalam jangka masa panjang, parameter kernel sahaja tidak mencukupi: geometri logik bagi partisi dan penggunaan TRIMmahupun teknologi seperti storan memori berterusanIa membawa perbezaan, terutamanya dalam pemuatan pangkalan data dan virtualisasi di mana pemecahan dan penulisan ganti adalah malar.

Perkara pertama yang perlu dilakukan ialah menyemak sama ada partition anda sejajar pada 1 MiBIni biasanya sesuai dengan geometri dalaman kebanyakan SSD moden. Dengan parted anda boleh mencipta susun atur yang bersih:

Pembahagian sejajar (berpisah): sudo parted -s /dev/nvme0n1 mklabel gpt
sudo parted -s /dev/nvme0n1 mkpart primary 1MiB 100%
sudo parted -s /dev/nvme0n1 align-check optimal 1

Di samping itu, banyak pemacu NVMe menawarkan pelbagai format LBA (LBAF) dengan saiz sektor yang berbezaBiasanya 512B dan 4K. Anda boleh melihat pilihan dan metrik RP (Prestasi Relatif) dengan:

Lihat format LBA: nvme id-ns -H /dev/nvme0n1 | grep -E 'LBA Format|Relative'

Jika anda memutuskan untuk berubah, sedarlah bahawa ia adalah operasi pemusnahan yang akan memadamkan semua kandungan pemacu. Satu contoh memilih format dengan indeks 1 ialah:

Tukar format LBA (operasi pemusnah): sudo nvme format /dev/nvme0n1 --lbaf=1

Bagi TRIM, ideanya adalah untuk memaklumkan unit blok mana yang tidak lagi mengandungi data yang sah supaya ia boleh guna semula tanpa penaltiPertama, periksa sama ada peranti menyokongnya dengan lsblk:

Semak sokongan TRIM: lsblk --discard

Jika anda melihat nilai DISC-GRAN yang bukan sifar, terdapat sokongan. Kebanyakan pengedaran terkini mendayakannya. pemasa mingguan fstrim yang merupakan pilihan yang disyorkan, lebih baik daripada menggunakan pilihan buang dalam /etc/fstab, yang menambah overhed pada setiap pemadaman:

Dayakan fstrim berkala: systemctl enable --now fstrim.timer
systemctl status fstrim.timer

Memilih dan memasang sistem fail pada NVMe

Lapisan sistem fail ialah penapis terakhir antara aplikasi anda dan NVMe. XFS dan ext4 berfungsi dengan sangat baik pada pelayan LinuxDan dalam kebanyakan kes, adalah dinasihatkan untuk menggunakan pilihan lalainya dengan sedikit pelarasan yang bertujuan untuk mengurangkan penulisan yang tidak perlu.

Pilihan yang sangat berkesan dengan hampir tiada kelemahan ialah waktu petangIni menghalang pengemaskinian masa akses terakhir setiap kali fail dibaca. Ini mengurangkan penulisan cakera, yang meningkatkan jangka hayat dan prestasi fail. Satu contoh dalam /etc/fstab dengan ext4 ialah:

Contoh fstab (ext4 noatime): /dev/nvme0n1p1 / ext4 noatime,errors=remount-ro 0 1

Dengan XFS, falsafahnya adalah sama: gunakan sistem fail lalai dan tambahkan noatime jika anda ingin melanjutkan jangka hayat SSD. Dalam kes ext4 dan XFS, ia adalah Sebaiknya TRIM berkala dengan fstrim.timer dan bukannya pilihan buang, kecuali untuk keperluan yang sangat khusus.

Jika anda menggunakan kad SD atau media boleh tanggal, perlu diingat bahawa banyak yang menggunakan FAT32 atau exFAT, yang mana Mereka tidak mempunyai jurnal atau TRIM.Dalam kes ini, penalaan lebih tertumpu pada memilih kad berkualiti dan berkapasiti lebih tinggi, dan meminimumkan penulisan dengan menukar /var/log, /tmp atau direktori dengan banyak I/O kepada tmpfs apabila ia masuk akal.

Pengoptimuman SSD/NVMe umum: noatime, tmpfs, swap dan pembalakan

Selain penalaan khusus NVMe, terdapat satu set tweak SSD klasik yang kekal sangat berkesan. Yang pertama ialah menyemak direktori mana yang mengalami tekanan paling tinggi. membaca dan menulis secara berterusan menggunakan iotop:

Pemantauan I/O masa nyata: iotop -oPa

Biarkan ia berjalan seketika dan anda akan melihat proses dan laluan mana yang diutamakan. Dari situ, anda boleh memindahkan beberapa direktori yang sangat tidak menentu ke tmpfs dalam RAMDengan syarat anda mempunyai banyak memori. Contoh tipikal dalam /etc/fstab:

Contoh tmpfs dalam fstab: tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
tmpfs /var/tmp tmpfs defaults,noatime,mode=1777 0 0

Dalam kebanyakan pengedaran Linux moden, /tmp sudah pun merupakan tmpfs, tetapi anda masih boleh memindahkan /var/tmp atau direktori bising lain ke dalam RAM. Pilihan lain ialah /var/log, jika anda tidak kisah kehilangan log antara but semula atau jika anda menghantar log ke syslog jauh.

tmpfs /var/log tmpfs defaults,noatime,mode=0755 0 0

Secara selari, semak semula konfigurasi jurnal sistemd dalam /etc/systemd/journald.conf untuk mengehadkan saiz log maksimum (SystemMaxUse, RuntimeMaxUse, dll.) dan tahap perincian (MaxLevelStore), mengelakkan ribut penulisan yang tidak perlu.

Satu lagi perkara penting untuk mana-mana SSD atau NVMe ialah penggunaan dasar pertukaran dan pertukaranMengurangkan nilai ini membolehkan kernel menggunakan RAM dengan lebih cekap dan mengurangkan penggunaan cakera:

Pelarasan swappiness: vm.swappiness=1

Jika anda mempunyai ingatan yang sangat baik dan menyedari risikonya, anda juga boleh menetapkannya kepada 0, walaupun dalam praktiknya biasanya lebih seimbang untuk menggabungkannya dengan zram atau zswapyang memampatkan dan mengurus swap dalam memori sebelum sampai ke cakera fizikal, sekali gus mengurangkan penulisan ke NVMe dengan ketara.

Mendiagnosis masalah sebenar berbanding penanda aras sintetik (fio, dd, salinan fail)

Bukan sesuatu yang luar biasa bagi seorang pentadbir untuk menghadapi situasi yang fio memberikan nombor yang sangat baik, tetapi salinan fail mudah atau pangkalan data SELECT INTO kelihatan sangat perlahanAdalah penting untuk memahami bahawa beban dunia sebenar tidak menyerupai penanda aras yang sempurna dan terdapat banyak lagi faktor yang terlibat.

Perintah seperti dd dengan bs=1M Mereka biasanya menunjukkan kelajuan yang dihadkan oleh lapisan sistem fail, cache halaman kernel, dd itu sendiri dan cara ia menulisBegitu juga, operasi besar-besaran dalam MSSQL, MySQL atau MariaDB pada ext4 atau XFS bukan sahaja mengukur NVMe, tetapi juga journaling, fsync, log flush, locking, CPU, kernel scheduler dan banyak lagi.

Jika pada pelayan dengan Epyc, sejumlah besar RAM dan pemacu NVMe mewah anda melihat bahawa sandaran tidak melebihi 1-2 GB/s, tetapi Fio melaporkan nilai yang hampir dengan spesifikasi, kemungkinan besar kesesakan itu terletak pada lapisan perisian (sistem fail, pangkalan data, konfigurasi jurnal, saiz log, dll.) atau bagaimana paralelisme digunakan (bilangan thread yang berkesan, had serentak dalam pangkalan data, dsb.).

Pendekatan praktikal adalah dengan menggabungkan alat peringkat rendah (fio, iostat, smart-log) dengan pengukuran peringkat aplikasi dan laraskan dalam lapisan: pertama kernel dan NVMe, kemudian sistem fail dan akhirnya pangkalan data dan pertanyaan itu sendiri.

Peranan perkakasan dan sistem pengendalian dalam prestasi pangkalan data

Apabila kita bercakap tentang penalaan pangkalan data Berkenaan NVMe, penting untuk diingat bahawa konfigurasi lalai jarang sekali mencukupi untuk pengeluaran. Piramid prestasi bermula dengan perkakasanCPU, jumlah RAM dan, yang paling penting, jenis penyimpanan.

Di dasar piramid itu terletak kualiti penyimpananHDD mekanikal tidak lagi sesuai untuk pangkalan data transaksi yang serius; SSD SATA adalah minimum yang boleh diterima; dan pemacu NVMe yang disambungkan melalui PCIe adalah standard emas kerana kependamannya yang rendah dan IOPS yang sangat tinggi.

Di atasnya ialah sistem pengendalian: bagaimana ia mengurus memori, cache halaman, I/O cakera dan penjadualan proses Ia secara langsung mempengaruhi pangkalan data. Tetapan seperti swappiness, pemilihan penjadual, penggunaan O_DIRECT dalam InnoDB, afiniti NUMA dan pelekap direktori dalam tmpfs boleh membuat lebih banyak perbezaan daripada perubahan parameter dalaman mudah dalam MySQL.

Barulah masuk akal untuk bertarung dengan konfigurasi pelayan pangkalan data (InnoDB, penimbal global, log, dll.) dan, di bahagian atas, dengan reka bentuk skema dan indeks serta dengan kualiti pertanyaan SQL.

MySQL/MariaDB pada NVMe: penalaan halus InnoDB untuk mengeksploitasi perkakasan

InnoDB ialah enjin storan lalai moden atas sebab tertentu: Ia menawarkan transaksi ACID, penguncian peringkat baris, rintangan yang baik terhadap rasuah dan keupayaan untuk mengendalikan keserentakan yang tinggi.Tetapi agar ia benar-benar bersinar, konfigurasinya perlu diselaraskan dengan perkakasan asas, terutamanya dengan pemacu NVMe yang pantas.

Parameter bintang ialah innodb_buffer_pool_saizIni menentukan berapa banyak RAM yang dikhaskan oleh InnoDB untuk mengekalkan data dan indeks panas dalam memori. Sebagai peraturan umum, pada pelayan pangkalan data khusus, antara 70% dan 80% daripada RAM yang tersedia dikhaskan untuk kolam penimbal, yang diselaraskan mengikut perkhidmatan lain yang berjalan pada mesin.

Apabila data terutamanya dimuatkan dalam kumpulan penimbal, bacaan diselesaikan dalam RAM dan NVMe digunakan terutamanya untuk penulisan log berjujukan dan pembilasan terkawalJika tidak, setiap kehilangan cache melibatkan perjalanan ke cakera, dan walaupun ia NVMe, el tiempo Masa tindak balas akan jauh lebih perlahan daripada akses memori.

Blok penalaan utama yang lain ialah Log InnoDB (innodb_log_file_size dan innodb_log_buffer_size)Log bersaiz betul membolehkan pengumpulan lebih banyak perubahan ke dalam penulisan berjujukan yang panjang, mengurangkan tekanan I/O rawak pada fail data:

• Fail log besar: Prestasi penulisan yang lebih tinggi tetapi masa pemulihan yang lebih lama selepas ranap, kerana lebih banyak peristiwa perlu dimainkan semula.
• Fail log kecil: Pemulihan yang lebih cepat tetapi berpotensi menjadi kesesakan dalam penulisan intensif.

Untuk memanfaatkan sepenuhnya NVMe, ia biasanya berbaloi untuk dimiliki kayu balak sedikit lebih besar daripada biasakerana pemacu boleh mengendalikan penulisan berjujukan dengan selesa dan masa pemulihan biasanya masih boleh diterima.

Keserentakan, thread dan I/O dalam InnoDB melalui NVMe

Dalam persekitaran dengan banyak CPU dan pemacu NVMe yang pantas, adalah menarik untuk mengubah suai parameter seperti innodb_thread_concurrency, innodb_read_io_threads dan innodb_write_io_threadsWalau bagaimanapun, dalam versi MySQL/MariaDB semasa, amalan biasa untuk membiarkan innodb_thread_concurrency pada 0 supaya enjin menguruskan keserentakan dalaman itu sendiri.

Apa yang penting ialah memastikan pelayan tidak kehabisan ruang. Benang untuk operasi baca dan tulis Dan lapisan bawah (kernel dan NVMe) bersedia untuk mengendalikan giliran I/O yang dalam apabila beban benar-benar memerlukannya. Dengan NVMe biasanya tiada masalah, tetapi adalah dinasihatkan untuk menggunakan alatan seperti Skema Prestasi atau skema sistem untuk menyemak menunggu I/O yang anomali.

Bagaimana InnoDB berinteraksi dengan sistem fail juga penting. Parameter innodb_flush_method=O_DIRECT Dalam Linux, ia mengelakkan penimbalan berganda dengan cache sistem fail dan menulis terus ke peranti, yang amat disyorkan apabila terdapat RAID dengan cache yang dilindungi atau NVMe dengan cache dalaman yang baik.

Pengurusan sambungan, penimbal sesi dan cache global

NVMe pantas tidak begitu berguna jika pelayan pangkalan data terlebih beban. beribu-ribu sambungan tidak aktif, penimbal sesi yang besar atau konfigurasi Query Cache yang ketinggalan zamanOleh itu, selain menala InnoDB, parameter umum juga perlu disusun.

Pembolehubah sambungan_paksimum mentakrifkan bilangan maksimum sambungan serentak yang dibenarkan. Meningkatkannya secara membuta tuli kerana "terdapat banyak RAM" adalah satu kesilapan: setiap sambungan menyeret penimbal dan struktur dalaman yang terkumpul dalam memori. Amalan terbaik adalah memantau Max_used_connections dan Laraskan max_connections sedikit di atas puncak sebenar, meninggalkan ruang tetapi tanpa keterlaluan.

`wait_timeout` menentukan berapa lama sambungan terbiar dikekalkan hidup sebelum ditutup. Nilai lalai dalam jam tidak begitu masuk akal dalam konteks ini. aplikasi web dengan kolam sambunganMengurangkannya kepada 60 atau 30 saat membantu mengosongkan sesi yang terbengkalai dan menghalang pengisian memori dengan sambungan "tidur".

Parameter saiz_cache_utas Tetapan ini mengawal bilangan thread yang disimpan dalam cache untuk digunakan semula pada sambungan baharu. Jika Threads_created jauh lebih tinggi daripada Connections, ia menunjukkan cache yang kecil. Melaraskan tetapan ini akan mengurangkan kos penciptaan thread dan meningkatkan daya tindak balas semasa letusan trafik.

Mengenai Query Cache, ia sudah ketinggalan zaman dalam MySQL moden dan biasanya tiada dalam MariaDB. menyebabkan lebih banyak masalah penyumbatan dan pembatalan berbanding manfaatnya pada sistem dengan kadar penulisan yang tinggi. Ia tidak menawarkan apa-apa yang istimewa berbanding NVMe, dan dalam kebanyakan kes, adalah lebih baik untuk melumpuhkannya.

Penimbal berfungsi setiap sesi: berhati-hati dengan ingatan

Parameter seperti saiz_penimbal_sort, saiz_penimbal_join dan saiz_penimbal_baca Ia diperuntukkan setiap thread apabila diperlukan, yang bermaksud bahawa nilai besar yang didarabkan dengan ratusan sambungan boleh menghabiskan RAM pada kelajuan penuh.

Penimbal ini digunakan untuk operasi tertentu (isihan tanpa indeks, gabungan tanpa indeks, bacaan berjujukan), dan hanya perlu berkembang untuk kes-kes tertentu bagi rundingan yang berat dan terkawalSecara global, adalah lebih baik untuk mengekalkan nilai-nilai konservatif dan, jika perlu, meningkatkannya berdasarkan kes demi kes dalam sesi penyelenggaraan atau proses kelompok, daripada menetapkan had yang besar untuk semua pelanggan.

Reka bentuk skema, indeks dan pertanyaan: lapisan tempat keuntungan paling banyak diperoleh

Tidak kira berapa banyak NVMe, penalaan kernel dan InnoDB yang anda miliki, jika jadual anda kekurangan indeks dan pertanyaan yang sesuai melakukan imbasan besar-besaran penuhPerkakasan tidak akan dapat menyelamatkan anda. Alat penting untuk melihat apa yang sedang berlaku ialah TERANGKAN.

Semasa menganalisis pelan pelaksanaan, beri perhatian kepada:

• Jenis: Jika anda melihat SEMUA dalam jadual besar, terdapat imbasan penuh dan anda perlu menambah indeks.
• kunci dan kunci_kekunci yang mungkin: indeks yang mana boleh digunakan dan yang mana sebenarnya digunakan.
• baris: Anggaran bilangan baris untuk diperiksa; lebih rendah, lebih baik.

Pengindeksan dengan betul adalah kunci. lajur yang digunakan dalam WHERE dan dalam syarat JOIN...serta menulis semula subpertanyaan berkorelasi dalam JOIN apabila mungkin. Reka bentuk indeks yang baik mengurangkan I/O yang diperlukan setiap pertanyaan dan dengan itu mengeksploitasi kependaman rendah NVMe dengan lebih baik.

Pada peringkat skematik, gunakan jenis data sekecil mungkinNormalisasi ke tahap yang munasabah dan mentakrifkan kekunci primer mudah (INT/BIGINT AUTO_INCREMENT) dalam InnoDB membantu menjadikan jadual lebih padat, lebih sesuai dalam kolam penimbal dan memanfaatkan cache dan perkakasan asas.

Pemantauan berterusan dan kitaran penalaan berulang

Semua penalaan ini sia-sia jika tidak Anda mengukur sebelum dan selepas bagi setiap perubahan. Untuk pangkalan data, Log Pertanyaan Perlahan, Skema Prestasi dan skema sistem membolehkan anda mencari pertanyaan perlahan, jadual dengan banyak imbasan penuh, indeks yang kurang digunakan atau fail yang terlalu banyak menumpukan I/O.

Alat luaran seperti Prometheus/Grafana, Percona PMM atau sistem pemantauan lain Ia memudahkan untuk melihat gambaran keseluruhan: purata latensi dan pertanyaan p95/p99, QPS, penggunaan CPU, giliran I/O, suhu dan kesihatan NVMe, dsb. Dengan maklumat tersebut, anda boleh menggunakan proses lelaran yang bijak:

• Takrifkan garis dasar prestasi (perkakasan + kernel + pangkalan data).
• Kenal pasti kesesakan yang dominan pada masa itu.
• Gunakan satu perubahan (cth., laraskan himpunan penimbal, tukar penjadual atau tambah indeks).
• Ukur sekali lagi dan tentukan sama ada perubahan itu kekal, diterbalikkan atau diubah suai.

Mengoptimumkan NVMe dan pangkalan data pada Linux bukanlah helah ajaib atau perubahan parameter terpencil, tetapi proses berterusan mengukur, memahami dan menyesuaikan diri secara berlapis-lapisDengan menggabungkan perkakasan yang baik (terutamanya NVMe yang berkualiti), kernel yang ditala dengan baik (APST, penjadual, NUMA, TRIM), sistem fail yang dikonfigurasikan dengan bijak (noatime, tmpfs jika sesuai), dan MySQL/MariaDB yang berparameter dengan baik dengan skema dan indeks yang kukuh, adalah sangat mungkin untuk membolehkan pelayan Linux anda benar-benar melepaskan potensi pemacu NVMe mereka di bawah beban kerja dunia sebenar, melangkaui penanda aras makmal sintetik.