Kami, di RUVDS, tidak memiliki server NVMe sejalan untuk membuatnya lebih cepat dan lebih kuat. .. Karena pada tahun lalu mode mulai digunakan pada Bitrix dan 1C seperti itu ... Ada permintaan untuk layanan ini, layanan hosting lain juga memilikinya dan dipesan - secara umum, semuanya mengarah pada kenyataan bahwa Anda hanya perlu memilih konfigurasi dan opsi perangkat keras tertentu dan membeli di 11 lokasi di seluruh dunia. Dan di sini saya harus mengatakan bahwa saat ini kami hanya mendukung dua konfigurasi: lebih cepat dan lebih lambat. Karena suku cadang, karena support, karena software dan sebagainya adalah salah satu bagian dari kebijakan harga yang memadai. Artinya, sepertiga akan ditambahkan, dan akan memungkinkan untuk mengubah sesuatu di sana dalam empat tahun.
Kami memiliki RAID SSD di mana-mana (bahkan di mana HDD ditampilkan dengan tarif), tetapi kami menginginkan yang lebih kuat, lebih tinggi, dan lebih cepat.
Hal pertama yang kami pelajari adalah bahwa NVMe tidak digabungkan ke dalam RAID dengan cara biasa, sehingga disk yang andal tidak diharapkan. Kedua, kami ingin mendorong Hi-CPU ke server yang sama dan terkejut menemukan bahwa frekuensi 4,5 GHz bukanlah server, tetapi perangkat keras desktop rumahan dan solusi server frekuensi seperti itu secara fisik belum ada.
Plus, dalam perjalanan, admin kami menemukan bug fatal di utilitas pengujian. Secara umum, izinkan saya memberi tahu Anda dengan pengujian seperti apa solusi NVMe di hosting VDS.
Saya harus segera mengatakan bahwa mungkin kami melakukan sesuatu yang salah, dan jika seseorang memahaminya, saya akan sangat berterima kasih.
Harapan dari NVMe
Ketika kami beralih dari HDD ke SSD, perbedaannya seperti surga dan bumi. Anda menjalankan tes apa pun dan Anda mendapatkan beberapa peningkatan kinerja. Ini tidak terjadi pada NVMe. Selain itu, dalam tabrakan langsung dengan konfigurasi NVMe kami yang ada, drive tidak selalu dapat mengatasinya. Mereka lebih cepat atau lebih lambat, tergantung pada kondisi tes.
Untuk memulai, kami membeli beberapa opsi server. Kami biasanya membeli platform, mengujinya, memahami apa yang salah, mengujinya lagi, kemudian hanya meluncurkannya ke 11 lokasi, karena begitu banyak suku cadang sekaligus dan proses pendukung baru mahal. Kemudian kami membeli platform dan segera menemukan hasil yang sangat timpang.
Dalam hypervisor yang sama pada sistem operasi tamu yang berbeda, tidak mungkin untuk membedakan antara SSD di dalam server atau NVMe. Bahkan dengan adonan.
Saat menggunakan NVMe dalam RAID, kecepatannya akan lebih lambat dari SSD. Secara kasar, ketika kami menggunakan RAID, kami memasukkannya ke dalam satu bus PCIe dan kami terbatas pada PCI Express ini, dan kami hanya dapat memparalelkan beberapa disk pada bus yang berbeda. Kami membutuhkan pengontrol.
Mengapa demikian, tidak ada yang bisa memberikan jawaban normal. Mereka bertanya kepada vendor lama yang terpercaya, vendor baru, dan umumnya vendor sayap kiri. Semua orang mengangkat bahu mereka dan berkata: "Yah, Anda biasanya pengisap, yang menempel NVMe di RAID - tidak akan ada kinerja!". Kata-katanya berbeda dari yang diberikan, tetapi artinya tetap tidak berubah. Jadi kami menyadari bahwa kami mungkin harus menggunakan NVMe tanpa serangan. Ada satu perusahaan (pesaing yang bersahabat) - jadi, hanya mereka yang menjelaskan bahwa mereka memiliki hal yang sama beberapa tahun yang lalu. Mereka membuang beberapa platform, dan pada akhirnya diputuskan untuk tidak menggunakan RAID.
Artinya, masalah pertama adalah ketika disk dilepaskan, tidak akan ada autorebuild untuk yang baru, yang akan dibawa oleh administrator. Tanpa RAID, klien akan kehilangan status dan data mesin virtual mereka. Tidak sama, tapi kami mencoba untuk melanjutkan.
Lalu ada pilihan antara U2 dan M2. Kami membeli pelek U2 yang mahal. Mereka terjebak melalui antarmuka Okulinka ke dalam bus. M2 lebih sering digunakan di desktop, mereka menempel di motherboard. Kami juga mengujinya, tidak ada banyak perbedaan di antara mereka. Tetapi jika disk macet langsung ke papan tanpa antarmuka perantara, maka lebih sulit untuk memperbaikinya - jika terjadi kegagalan, Anda harus melepas penutup server dan melihat-lihat.
Sekarang tes adalah realitas NVMe
Hasilnya tergantung pada OS host, versi hypervisor, versi OS rumahan pada mesin virtual, dan pilihan metode pengujian.
Itu tergantung pada fakta bahwa hypervisor terbaru mendukung NVMe dengan driver mereka secara asli, sementara yang lain bekerja sebagai overhead SSD. Ini juga bukan hasil yang baik, karena kami terbiasa menggunakan solusi yang sudah terbukti. Ada server Windows 12-16-19. Kami menggunakan versi maksimum 16. Ketika yang berikutnya keluar, kami akan menggunakan 19. Karena versi terbaru selalu beta. Secara umum, hanya geeks dan bunuh diri yang menggunakan versi terbaru dari perangkat lunak dalam administrasi server. Dan ya, jika tangan Anda berkedut sekarang, Anda adalah seorang geek. Atau penguji beta. Meskipun, Anda mungkin belum mengetahuinya. Vendor perangkat lunak secara teratur meluncurkan versi baru, memberikan reboot, pembaruan, tambalan - Anda harus melewati satu generasi agar dapat bekerja secara stabil. Seperti biasa, kami menunggu paket layanan kedua. Anda tidak dapat menjelaskan kepada klien tentang kerentanan baru atau paket pembaruan baru dari MS. Lebih tepatnya,kami dapat menjelaskan, tetapi klien tidak selalu percaya. Dengan armada mobil kami di Windu ke-19, sangat tidak baik untuk dijalankan. Jika semua server mulai melakukan musik berwarna dengan pembaruan dan reboot, Anda tidak ingin bersusah payah.
Poin penting kedua menyangkut keanehan pada file 45 GB, Anda akan lihat sekarang.
Metodologi: selama pengujian, kami menggunakan utilitas diskspd . CrystalDiskMark kacau di sekitarnya , yang ingin kami gunakan terlebih dahulu, tetapi kami menemukan satu bug yang sangat lucu.
Penting bagi kami bahwa kedua utilitas:
- Memungkinkan Anda menentukan beberapa file pengujian secara bersamaan. Selain itu, file-file ini dapat ditemukan di disk yang berbeda. Ini dapat berguna untuk memeriksa keseluruhan keluaran pengontrol saat membaca secara independen pada disk yang berbeda. Jumlah benang. Berapa banyak utas yang independen satu sama lain akan dibuat yang akan membaca dan menulis file.
- Dalam jumlah diskspd permintaan IO yang beredar per utas - mungkin ada beberapa perbedaan dalam terjemahan. Selain itu, di CrystalDiskMark parameter ini disebut Queue, meskipun hampir tidak bisa disebut antrian.
Memahami jumlah parameter IO yang luar biasa
Untuk memahami cara kerja utilitas, kita dapat melihat kode sumbernya. Baris berikut paling menarik.
Untuk dibaca:
if (useCompletionRoutines) { rslt = ReadFileEx(...); } else { rslt = ReadFile(...); }
Dan baris serupa untuk ditulis:
if (useCompletionRoutines) { rslt = WriteFileEx(...); } else { rslt = WriteFile(...); }
Argumen dihilangkan untuk kejelasan. Kami lebih tertarik pada fakta bahwa membaca dan menulis dilakukan oleh fungsi WinAPI standar:
ReadFile
WriteFile
Dan fungsi asinkron yang sesuai:
ReadFileEx
WriteFileEx
Jika Anda melihat lebih dekat pada kode, Anda dapat memahami hal berikut:
Saat mengatur jumlah yang beredar IO = 1 , opsi ReadFile dan WriteFile sinkron akan digunakan. Pseudocode untuk operasi tulis terlihat seperti ini:
void testThreadFunc() { while (!stopTesting) { WriteFile(...) // } }
Jika Anda mengatur jumlah IO> 1 yang luar biasa , maka opsi ReadFileEx dan WriteFileEx asinkron akan digunakan, dan jumlah IO yang luar biasa menetapkan kedalaman panggilan tersebut untuk setiap utas. Pseudocode untuk operasi tulis dengan jumlah IO = 3 yang luar biasa terlihat seperti ini:
void callback1() { while (!stopTesting) { WriteFileEx(..., callback1) } } void callback2() { while (!stopTesting) { WriteFileEx(..., callback2) } } void callback3() { while (!stopTesting) { WriteFileEx(..., callback3) } } void testThreadFunc() { WriteFileEx(..., callback1) // WriteFileEx(..., callback2) // WriteFileEx(..., callback3) // // }
Dengan demikian, jumlah IO yang beredar adalah jumlah panggilan asinkron di setiap utas.
Mengapa kami tidak menggunakan CrystalDiskMark
Utilitas CrystalDiskMark hanyalah antarmuka grafis untuk diskspd . Sangat mudah untuk menebaknya jika Anda menginstal utilitas dan pergi ke direktori CdmResource \ DiskSpd.
Tetapi ada sejumlah masalah dengan implementasi shell ini.
Pertama, ia memodifikasi kode diskspd dalam beberapa cara . Sangat mudah untuk memahami jika Anda melihat kode CrystalDiskMark :
command.Format(L"\"%s\" %s -d%d -A%d -L \"%s\"", ..., GetCurrentProcessId(), ...);
Saat memanggil diskspd, parameter -A diteruskan dengan Id dari proses saat ini. Diskspd tidak memiliki parameter seperti itu. Penulis CrystalDiskMark memutuskan untuk tidak mengurai keluaran konsol diskspd dan memutuskan untuk mendapatkan data dengan cara yang lebih rumit. Apalagi metode yang dipilih bukanlah yang paling berhasil.
Dalam fungsi ini, diskspd dipanggil secara langsung :
int ExecAndWait(TCHAR *pszCmd, BOOL bNoWindow, double *latency) { DWORD Code = 0; … GetExitCodeProcess(pi.hProcess, &Code); *latency = (double)*pMemory * 1000; // milli sec to micro sec return Code; }
Pada prinsipnya, tidak ada pertanyaan tentang mentransfer latensi melalui SharedMemory . Tetapi jika kita mempertimbangkan lebih lanjut pada kode di mana nilai variabel Kode digunakan , menjadi jelas bahwa ini adalah kecepatan disk yang diukur. Bukan ide yang baik untuk mengembalikannya melalui ErrorCode dari proses. Misalnya, jika proses berakhir dengan kesalahan karena alasan lain, maka kode kesalahan hanya akan ditampilkan sebagai hasil pengujian.
Ada juga keraguan tentang kebenaran nilai pengembalian latensi . Saat menentukan sakelar -L, diskspd mengembalikan sesuatu seperti ini:
Misalnya, baris keenam berarti bahwa 95% dari waktu latensi akan kurang dari 54,306 md . CrystalDiskMark hanya mengembalikan rata-rata dari semua nilai dalam tabel. Ini bisa menyesatkan.
Parameter uji
Untuk melihat manfaat NVME, Anda perlu mengatur jumlah IO yang beredar cukup besar. Kami memilih nomor 32.
❒ Platform:
Supermicro SuperServer SYS-6029P-WTRT 2U
❒ Drives:
Intel SSD DC P4610 Series 1.6TB, 2.5in PCIe 3.1 x4, 3D2, TLC
❒ Perintah untuk menjalankan diskspd file 10G:
DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c10G G:/testfile.dat DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c10G G:/testfile.dat DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c10G G:/testfile.dat
❒ Perintah untuk menjalankan diskspd file 50G:
DiskSpd64.exe -b128K -t32 -o32 -w0 -d10 -si -S -c50G G:/testfile.dat DiskSpd64.exe -b128K -t32 -o32 -w100 -d10 -si -S -c50G G:/testfile.dat DiskSpd64.exe -b4K -t32 -o32 -w30 -d10 -r -S -c50G G:/testfile.dat
Hasil
❒ Tabel 1 Windows Server 2019 OS Host
|
|
SSD RAID 5 |
NVME U.2 |
|
Windows Server 2016 Virtual Server 10GB File (IOPS - lebih banyak lebih baik) |
11636 |
246813 |
|
Windows Server 2016 Virtual Server 45GB file (IOPS - lebih banyak lebih baik) |
9124 |
679 |
|
Server Virtual Debian 10 file 10GB (IOPS - lebih banyak lebih baik) |
- |
162748 |
|
File server virtual Debian 10 45GB (IOPS - lebih banyak lebih baik) |
- |
95330 |
❒ Tabel 1 Windows Server 2016 OS Host
|
|
SSD RAID 5 |
NVME U.2 |
|
Windows Server 2016 Virtual Server 10GB File (IOPS - lebih banyak lebih baik) |
11728 |
101350 |
|
Windows Server 2016 Virtual Server 45GB file (IOPS - lebih banyak lebih baik) |
11200 |
645 |
|
Server Virtual Debian 10 file 10GB (IOPS - lebih banyak lebih baik) |
10640 |
52145 |
|
File server virtual Debian 10 45GB (IOPS - lebih banyak lebih baik) |
9818 |
39821 |
Di bawah Hyper-V dan tamu Windows Server, hasilnya sulit dijelaskan. Pada file kecil sekitar 10G, kami mendapatkan peningkatan besar dalam IOPS dibandingkan dengan SSD dalam serangan. Tetapi jika kita mengambil file 45G , sebaliknya, kita mendapatkan penurunan IOPS yang signifikan .
Sekarang ke Hi-CPU
Kejutan kedua dibuka pada prosesor 4,5 GHz.
Harus dikatakan di sini bahwa prosesor di baris server juga digunakan oleh generasi -1 dari desktop. Karena penguji beta adalah gamer dan Anda dapat mengirimkan patch perangkat lunak kepada mereka. Tetapi di server, bahkan heartblade yang sama tidak segera diperbaiki, dan tidak semuanya. Semua solusi server dapat diandalkan dan mahal, tetapi kecepatannya selalu lebih rendah.
Kami memiliki tugas non-desktop. Mesin dibagi di antara banyak pelanggan. Dan sekarang kita melihat konfigurasi pada 4,5 GHz, yang tidak alami.
Ternyata ada dua implementasi:
- Hi-CPU ( , ). , , . .
- , turbo boost-, . ! - 3,6 4,5 . , -, : . ( ), . .
▍
Akibatnya, kami memutuskan untuk tetap menggunakan 3,6 GHz (turbo boost 4,4 GHz) yang telah terbukti dan dengan demikian menutup penelitian dengan prosesor.
Dengan NVMe - setelah mengambil hasil acak dari utilitas superstandar, seperti yang Anda lihat, kami mengubah alatnya. Berikutnya adalah pertanyaan tentang hypervisor dan OS.
Secara komersial, disk ini menawarkan lebih dan lebih, Anda harus belajar bekerja. Untuk kami sendiri, kami meninggalkan kombinasi tertentu dari versi host hypervisor dan kami akan terus menguji, menyajikan disk juga. Jika hoster menulis NVMe, itu belum berarti apa-apa. Pada KVM dengan rakitan * nix baru dan konfigurasi yang melelahkan, Anda bisa mendapatkan keuntungan yang sangat baik, tetapi setiap tes harus ditandai dengan tanda bintang - "dalam kondisi seperti itu, jika Anda sedikit berubah, dan secara umum semuanya tidak begitu". Pada Windows atau Debian ke-12, semuanya berbeda.
Secara umum, NVMe adalah standar tanpa syarat, tetapi sejauh ini tidak berarti pasti akan lebih cepat dengannya. Kami menyebarkan server dengan hati-hati, tetapi selama keuntungan kira-kira sesuai dengan kenaikan harga, tidak ada keajaiban.
