Rumah > pembangunan bahagian belakang > Golang > Adakah Pengumpul Sampah Go 1.5 Sedia untuk Pengurusan Memori Skala Terabyte?

Adakah Pengumpul Sampah Go 1.5 Sedia untuk Pengurusan Memori Skala Terabyte?

DDD
Lepaskan: 2024-11-30 14:26:12
asal
366 orang telah melayarinya

Is Go 1.5's Garbage Collector Ready for Terabyte-Scale Memory Management?

Berapa Lajukah Go 1.5 GC dengan Terabait RAM?

Latar Belakang:

Java menghadapi masa gangguan GC A kesesakan yang terlalu lama tidak dapat menggunakan terabait memori dengan berkesan. Memandangkan Go GC dioptimumkan, orang ramai pasti tertanya-tanya sama ada ia boleh mencapai masa gangguan GC yang cukup singkat dalam persekitaran memori peringkat terabait.

Soalan:

  • Adakah Go 1.5 GC bersedia untuk mengendalikan terabait memori?
  • Adakah terdapat tanda aras yang berkaitan?
  • Adakah mungkin menggunakan bahasa dengan GC untuk mengurus memori yang begitu besar?

Jawapan:

Mata:

  • Pada masa ini, satu proses Go tidak boleh menggunakan terabait ingatan . Had maksimum pada Linux ialah 512 GB, manakala yang tertinggi direkodkan dalam ujian dunia sebenar hanya 240 GB.
  • Dalam mod GC latar belakang semasa, beban kerja GC selalunya lebih kritikal daripada masa gangguan GC.
  • Beban kerja GC boleh diwakili oleh bilangan penunjuk * kadar peruntukan / baki memori. Dalam aplikasi yang menggunakan banyak memori, hanya aplikasi dengan bilangan penunjuk yang lebih kecil atau peruntukan yang lebih sedikit boleh mengekalkan beban kerja GC yang rendah.

Butiran:

Timbunan Go mempunyai had 512 GB, dan saiz timbunan maksimum sebenar yang diuji ialah 240 GB.

Go 1.5 GC direka untuk mengurangkan masa gangguan GC, bukan mengurangkan kerja GC. Kod terganggu semasa GC mengimbas tindanan dan penunjuk dalam pembolehubah global.

Menurut carta daripada ceramah GopherCon 2015, 1.5 GC mempunyai masa gangguan yang lebih pendek dalam penanda aras GC dengan timbunan ~18GB, seperti yang ditunjukkan:

[Carta: masa gangguan GC Hubungan dengan timbunan saiz, menunjukkan peningkatan dalam versi 1.5]

Dalam aplikasi sebenar, beberapa masa gangguan GC asal adalah Laporan proses sebanyak 300ms menurun kepada 4ms dan 20ms, dan aplikasi lain melaporkan masa GC persentil ke-95 daripada 279ms kepada 10ms.

Go 1.6 dioptimumkan lagi dan meletakkan beberapa kerja di latar belakang. Hasilnya ialah walaupun saiz timbunan melebihi 200GB, masa gangguan maksimum dalam ujian masih 20ms, seperti yang ditunjukkan dalam rajah berikut:

[Carta: Masa 1.6 GC berubah dengan saiz timbunan, mencapai 20ms sekitar 180GB]

Dalam versi 1.6, saiz timbunan adalah kira-kira 8GB dan aplikasi memperuntukkan kira-kira 150M seminit Masa gangguan adalah dari 20ms dikurangkan kepada 3-4ms.

Twitch menggunakan Go untuk menjalankan perkhidmatan sembang mereka, dan mereka melaporkan bahawa dalam versi 1.7, masa jeda telah dikurangkan kepada 1ms sambil menjalankan sejumlah besar coroutine secara serentak.

1.8 Alihkan pengimbasan tindanan keluar daripada fasa berhenti-the-world, mengekalkan masa gangguan paling banyak di bawah 1ms, walaupun dengan timbunan yang besar. Keputusan ujian awal menunjukkan keadaan yang baik. Kadangkala masih terdapat corak kod dalam aplikasi yang menjadikan coroutine sukar untuk diganggu, dengan berkesan memanjangkan masa gangguan untuk semua urutan lain, tetapi secara keseluruhan kerja latar belakang GC biasanya lebih penting daripada masa gangguan GC.

Pemerhatian am:

  • Kekerapan pengumpulan GC bergantung pada kelajuan penggunaan memori.
  • Jumlah kerja yang dilakukan oleh setiap koleksi GC bergantung sebahagiannya pada bilangan penunjuk yang digunakan. (Termasuk penunjuk dalam kepingan, nilai antara muka, rentetan, dll.)

Dalam erti kata lain, walaupun aplikasi akan mengakses banyak memori, jika bilangan penunjuk adalah kecil (mis., ia mengendalikan penimbal bait [] yang agak sedikit), dan kadar peruntukan adalah rendah (contohnya, kerana penyegerakan.Pool digunakan untuk menggunakan semula memori dalam senario limpahan memori yang paling terdedah), masalah GC mungkin tidak wujud.

Jadi, jika anda mempertimbangkan komputer besar dengan timbunan ratusan GB, dan ia sememangnya tidak sesuai untuk GC, saya cadangkan anda mempertimbangkan pilihan berikut:

  1. Gunakan C atau serupa Bahasa Penulisan
  2. mengalihkan sejumlah besar data keluar daripada graf objek, mis. untuk mengurusnya sebagai pangkalan data terbenam (mis Bolt), ke dalam perkhidmatan pangkalan data luaran, atau jika anda memerlukan lebih banyak keupayaan caching daripada pangkalan data, anda boleh menggunakan alat caching seperti groupcache atau memcache.
  3. Jalankan satu set proses yang menggunakan timbunan yang lebih kecil dan bukannya satu proses yang besar.
  4. Prototaip, diuji dan dioptimumkan dengan teliti untuk mengelakkan masalah ingatan.

Atas ialah kandungan terperinci Adakah Pengumpul Sampah Go 1.5 Sedia untuk Pengurusan Memori Skala Terabyte?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!

sumber:php.cn
Kenyataan Laman Web ini
Kandungan artikel ini disumbangkan secara sukarela oleh netizen, dan hak cipta adalah milik pengarang asal. Laman web ini tidak memikul tanggungjawab undang-undang yang sepadan. Jika anda menemui sebarang kandungan yang disyaki plagiarisme atau pelanggaran, sila hubungi admin@php.cn
Tutorial Popular
Lagi>
Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan