Berjalan di tmpfs akan lebih cepat hanya jika Anda memiliki banyak I/O disk yang tidak terpenuhi dari cache halaman.
Jika I/O dibaca dan file sudah ada di cache, tmpfs tidak akan membuat perbedaan.
Jika I/O adalah penulisan asinkron tanpa pembilasan dan beban kerjanya meledak alih-alih berkelanjutan dan ada cukup cache untuk menyerap rentetan penulisan dan penulisan dapat dibilas di latar belakang di antara rentetan, tmpfs tidak akan membuat perbedaan.
Jika tidak ada I/O disk yang harus dilakukan, tmpfs tidak akan membuat perbedaan.
Jika Anda memiliki banyak disk I/O dan proses Anda diblokir menunggu penyimpanan untuk mengejar ketinggalan, menjalankan tmpfs akan membuat perbedaan besar. Semakin lambat disk Anda, semakin banyak perbedaan yang dihasilkannya, sampai pada titik di mana Anda mengalami kemacetan CPU.
(4) File yang dapat dieksekusi dijalankan dari dalam container Docker, dan file yang dapat dieksekusi serta semua file yang terlibat berada dalam folder tmpfs yang dibuat dari dalam container, di bawah drive "internal" (yang tidak bertahan setelah container dihentikan).
(5) File yang dapat dieksekusi dijalankan dari dalam wadah Docker, dan file yang dapat dieksekusi serta semua file yang terlibat berada dalam folder disk "biasa".
Selain tmpfs (yang telah dialamatkan), Anda tidak akan melihat perbedaan apa pun antara menjalankan executable di host dan dari dalam wadah Docker. Sama dengan penyimpanan volume. Docker menjalankan keduanya menggunakan sistem file overlay dan mungkin ada yang sangat performa kecil mencapai overlay tetapi host melihat executable berjalan sebagai proses seperti jika dijalankan di host.
Secara realistis, harus ada perbedaan mendekati nol atau nol. Mungkin ada alasan yang sah untuk melakukan hal seperti itu, tetapi saya yakin 99,9% dari semua kasus itu adalah anti-pengoptimalan.
I/O normal akan masuk ke cache buffer, dan halaman kotor akan ditulis secara asinkron oleh utas kernel. Bandwidth =Kecepatan RAM, delay =RAM delay (plus, mungkin beberapa µs untuk kesalahan halaman di sana-sini).
Ketika sistem kehabisan RAM fisik, Anda akan memblokir (jelas), tidak ada cara lain. Ketika tidak ada halaman tersisa yang dapat Anda tulis, Anda harus menunggu sampai ada yang dibebaskan. Tidak ada jalan lain.
Kehabisan RAM, bagaimanapun, menurut definisi, tidak mungkin (atau mungkin) terjadi dalam kasus khusus Anda. Jika tidak, jika ada kemungkinan kehabisan RAM, ide membuat tmpfs akan sangat bodoh sejak awal.
I/O ke tmpfs akan menuju ke ... buffer cache. Ya, sekarang berjalan dengan nama yang berbeda, tetapi kenyataannya persis sama, karena sistem VM terpadu. Dengan demikian, bandwidth dan penundaan persis sama (memberi atau menerima mungkin perbedaan 1% karena seluk-beluk sistem file yang mungkin sedikit berbeda). Tidak ada writeback yang terjadi, ya. Tapi siapa yang peduli, melihat bagaimana itu akan terjadi secara tidak sinkron. Sebaliknya, sekarang Anda tidak memiliki kemewahan seseorang membebaskan halaman kotor di latar belakang, jadi kemungkinan untuk mencapai langit-langit, jika memungkinkan, sebenarnya lebih tinggi.
Saat sistem kehabisan RAM fisik, Anda masih hanya menulis ke halaman yang dipetakan di memori, jadi secara teori Anda seharusnya bisa melakukannya lebih cepat. Namun, dalam praktiknya, masih ada begitu-dan-banyak RAM fisik, dan Anda baru saja kehabisan itu! Tentu, mungkin masih ada ruang di tmpfs Anda, tetapi karena alasan tertentu, Anda juga perlu menulis halaman memori jika tidak, dan tidak ada yang tersisa.
Jadi kernel harus melakukan sesuatu untuk menjaga agar sistem tetap berjalan. Itu harus entah bagaimana mengatur ulang sumber dayanya untuk mengurangi masalah (mungkin menukar proses buruh pelabuhan dan seluruh wadah?!). Kernel akan berusaha keras, tetapi tidak seperti dapat melakukan sihir, ia harus melakukan sesuatu , dan pilihannya terbatas. Terlebih lagi karena Anda telah dengan sengaja mengambil sejumlah besar halaman yang dapat digunakan secara bebas sesuai kebutuhan untuk tujuan apa pun (termasuk permintaan yang harus dilayani sekarang).