Pertimbangan performa

Halaman ini memberikan panduan tentang cara mengonfigurasi lingkungan Parallelstore untuk mendapatkan performa terbaik.

Rekomendasi umum

  • Hapus alias dari ls untuk meningkatkan performa default. Di banyak sistem, aliasnya adalah ls -color=auto yang jauh lebih lambat dengan konfigurasi Parallelstore default.

  • Jika performa operasi daftar lambat, pertimbangkan untuk mengaktifkan penyimpanan dalam cache untuk mount dfuse.

Library intersepsi

Library libioil dapat digunakan untuk meningkatkan performa operasi baca dan tulis ke DFuse dari aplikasi yang menggunakan libc. Library mengabaikan kernel dengan mencegat panggilan baca dan tulis POSIX dari aplikasi agar dapat melayaninya secara langsung di ruang pengguna. Lihat Library intersepsi untuk mengetahui detail selengkapnya.

Dalam sebagian besar kasus, sebaiknya gunakan library intersepsi pada pemanggilan per proses atau per aplikasi.

Situasi saat Anda mungkin tidak ingin atau perlu menggunakan library intersepsi meliputi hal berikut:

  • Hanya aplikasi yang dibuat dengan libc yang dapat menggunakan library intersepsi.
  • Jika Anda memiliki beban kerja yang mendapatkan manfaat dari penyimpanan dalam cache, seperti mengakses file yang sama berulang kali, sebaiknya jangan gunakan library intersepsi.
  • Jika beban kerja Anda intensif metadata, seperti menggunakan banyak file kecil, atau listingan direktori yang sangat besar, library intersepsi kemungkinan tidak akan meningkatkan performa.

Pemanggilan LD_PRELOAD dapat ditetapkan sebagai variabel lingkungan di lingkungan shell, tetapi melakukannya terkadang dapat menyebabkan masalah. Sebaiknya tentukan dengan setiap perintah.

Atau, Anda dapat menautkan library intersepsi ke dalam aplikasi pada waktu kompilasi dengan flag -lioil.

Cache dfuse

Caching diaktifkan di dfuse secara default.

Ada dua flag terkait cache yang digunakan oleh dfuse saat memasang instance Parallelstore:

  • --disable-wb-cache menggunakan cache write-through, bukan cache write-back.
  • --disable-caching menonaktifkan semua penyimpanan dalam cache.

Saran berikut berlaku untuk penyimpanan dalam cache dan performa:

  • Jika Anda menggunakan library intersepsi, caching write-back akan dilewati. Sebaiknya tentukan --disable-wb-cache saat menggunakan library intersepsi.
  • Jika beban kerja Anda melibatkan pembacaan banyak file sekaligus, Anda harus menonaktifkan penyimpanan dalam cache.
  • Untuk workload yang melibatkan banyak klien yang mengubah file, dan update harus segera tersedia untuk klien lain, Anda harus menonaktifkan penyimpanan dalam cache.
  • Jika beban kerja Anda membaca file yang sama berulang kali, penyimpanan dalam cache dapat meningkatkan performa. Hal ini terutama berlaku jika file sesuai dengan memori klien Anda. dfuse menggunakan cache halaman Linux untuk penyimpanan cache-nya.

  • Untuk workload yang terdiri dari I/O kecil hingga file besar, selain mengaktifkan penyimpanan dalam cache, meningkatkan read-ahead dfuse mungkin bermanfaat. Untuk meningkatkan pra-baca dfuse, setelah dfuse dipasang, jalankan perintah berikut:

    echo 4096 > /sys/class/bdi/\$(mountpoint -d /mnt)/read_ahead_kb
echo 100 > /sys/class/bdi/\$(mountpoint -d /mnt)/max_ratio

Jika workload Anda melibatkan campuran skenario sebelumnya, Anda dapat memasang instance Parallelstore yang sama ke beberapa titik pemasangan dengan setelan cache yang berbeda.

Jumlah thread dan jumlah antrean peristiwa

Saat memasang instance Parallelstore, sebaiknya gunakan nilai berikut untuk --thread-count dan --eq-count:

  • Nilai jumlah thread tidak boleh melebihi jumlah core vCPU.
  • Nilai jumlah thread maksimum yang direkomendasikan adalah antara 16 dan 20. Di luar jumlah ini, manfaat performanya sedikit atau tidak ada, terlepas dari jumlah core yang tersedia.
  • Nilai antrean peristiwa harus setengah dari nilai jumlah thread.

Jika beban kerja Anda melibatkan operasi file kecil dalam jumlah sangat besar dan akses metadata yang berat, Anda dapat bereksperimen dengan meningkatkan jumlahnya di luar rekomendasi ini.

Setelan striping file

File striping adalah teknik penyimpanan data yang membagi file menjadi blok, atau strip, dan mendistribusikannya di beberapa target penyimpanan. File striping dapat meningkatkan performa dengan memungkinkan pembacaan dan penulisan paralel ke lebih dari satu target penyimpanan yang mendukung instance.

Saat membuat instance Parallelstore, Anda dapat menentukan salah satu dari tiga setelan striping file:

  • Minimum
  • Seimbang
  • Maksimum

Setelan ini dapat berdampak signifikan pada performa Parallelstore Anda. Untuk sebagian besar beban kerja, sebaiknya gunakan setelan seimbang, yang seharusnya merupakan kompromi yang wajar untuk sebagian besar beban kerja. Jika performa dengan setelan yang seimbang tidak dapat diterima:

  • Setelan minimum dapat meningkatkan performa untuk beban kerja dengan banyak file kecil, terutama jika ukuran file rata-rata kurang dari 256 KB.

  • Setelan maksimum dapat meningkatkan performa untuk workload dengan file yang sangat besar, umumnya lebih besar dari 8 GB, terutama jika banyak klien berbagi akses ke file yang sama.

Untuk penyesuaian lanjutan, alat daos menyediakan setelan per file atau per direktori. Bereksperimen dengan penyesuaian lanjutan memiliki risiko terkait performa dan umumnya tidak direkomendasikan. Lihat Memahami Redundansi Data dan Sharding di DAOS untuk mengetahui detail selengkapnya.

Setelan striping direktori

Saat membuat instance Parallelstore, Anda dapat menentukan salah satu dari tiga setelan striping direktori:

  • Minimum
  • Seimbang
  • Maksimum

Untuk sebagian besar beban kerja, sebaiknya gunakan setelan maksimum.

Untuk beban kerja yang melibatkan banyak listingan direktori besar, setelan seimbang atau minimum dapat menghasilkan performa daftar yang lebih baik. Namun, performa operasi lain, terutama pembuatan file, dapat terpengaruh.

multi-pengguna

Saat menggunakan alat dfuse untuk memasang instance Parallelstore, sebaiknya tentukan flag --multi-user. Flag ini memberi tahu kernel untuk menyediakan sistem file bagi semua pengguna di klien, bukan hanya pengguna yang menjalankan proses DFuse. DFuse kemudian akan muncul seperti sistem file multi-pengguna umum dan panggilan chown dan chgrp standar diaktifkan. Semua entri sistem file dimiliki oleh pengguna yang membuatnya seperti biasa dalam sistem file POSIX,

Saat menentukan tanda --multi-user, Anda juga harus mengupdate /etc/fuse.conf sebagai root dengan menambahkan baris berikut:

user_allow_other

Tampaknya tidak ada implikasi performa untuk memasang instance Anda sebagai multi-pengguna.

Setelan coding penghapusan

Erasure coding ditetapkan ke 2+1. Setelan ini tidak dapat diubah. Semua I/O yang tidak menggunakan EC2+1 akan ditolak.

Alokasi resource penampung sidecar Google Kubernetes Engine

Pada umumnya, performa yang tidak memuaskan dengan Google Kubernetes Engine dan Parallelstore disebabkan oleh CPU atau memori yang tidak memadai yang dialokasikan ke penampung sidecar Parallelstore. Untuk mengalokasikan resource dengan benar, pertimbangkan saran berikut:

  • Baca pertimbangan yang ditandai dalam Mengonfigurasi resource untuk penampung sidecar. Anda akan mempelajari alasan Anda mungkin perlu meningkatkan alokasi resource, dan cara mengonfigurasi alokasi resource penampung sidecar menggunakan anotasi Pod.

  • Anda dapat menggunakan nilai 0 untuk menonaktifkan batas atau permintaan resource di cluster Standar. Misalnya, dengan menetapkan gke-parallelstore/cpu-limit: 0 dan gke-parallelstore/memory-limit: 0, batas CPU dan memori penampung sidecar akan kosong, dan permintaan default akan digunakan. Setelan ini berguna jika Anda tidak tahu jumlah resource yang diperlukan dfuse untuk workload dan ingin dfuse menggunakan semua resource yang tersedia di node. Setelah mengetahui jumlah resource yang diperlukan dfuse berdasarkan metrik beban kerja, Anda dapat menetapkan batas yang sesuai.

  • Di cluster Autopilot, Anda tidak dapat menggunakan nilai 0 untuk membatalkan penetapan batas dan permintaan resource penampung sidecar. Anda harus menetapkan batas resource yang lebih besar secara eksplisit untuk penampung sidecar di cluster Autopilot, dan mengandalkan metrik Google Cloud untuk memutuskan apakah perlu meningkatkan batas resource.