🥇Selam dalam statistik dalaman PostgreSQL. Alexey Lesovsky

Transkripsi laporan 2015 oleh Alexey Lesovsky "Selam mendalam ke dalam statistik dalaman PostgreSQL"

Penafian daripada pengarang laporan: Saya ambil perhatian bahawa laporan ini bertarikh November 2015 - lebih daripada 4 tahun telah berlalu dan banyak masa telah berlalu. Versi 9.4 yang dibincangkan dalam laporan tidak lagi disokong. Sepanjang 4 tahun yang lalu, 5 keluaran baharu telah dikeluarkan di mana banyak inovasi, penambahbaikan dan perubahan berkaitan statistik telah muncul, dan beberapa bahan sudah lapuk dan tidak relevan. Semasa saya menyemak, saya cuba menandakan tempat-tempat ini supaya tidak mengelirukan anda pembaca. Saya tidak menulis semula tempat-tempat ini, terdapat banyak daripada mereka, dan akibatnya, laporan yang sama sekali berbeza akan muncul.

DBMS PostgreSQL ialah mekanisme yang besar, dan mekanisme ini terdiri daripada banyak subsistem, kerja yang diselaraskan secara langsung mempengaruhi prestasi DBMS. Semasa operasi, statistik dan maklumat tentang pengendalian komponen dikumpul, yang membolehkan anda menilai keberkesanan PostgreSQL dan mengambil langkah untuk meningkatkan prestasi. Walau bagaimanapun, terdapat banyak maklumat ini dan ia dibentangkan dalam bentuk yang agak mudah. Memproses maklumat ini dan mentafsirnya kadangkala merupakan tugas yang tidak penting, dan "zoo" alatan dan utiliti boleh mengelirukan dengan mudah walaupun DBA lanjutan.

Selamat petang Nama saya Aleksey. Seperti yang Ilya katakan, saya akan bercakap tentang statistik PostgreSQL.

Statistik aktiviti PostgreSQL. PostgreSQL mempunyai dua statistik. Statistik aktiviti, yang akan dibincangkan. Dan statistik penjadual tentang pengagihan data. Saya akan bercakap secara khusus tentang statistik aktiviti PostgreSQL, yang membolehkan kami menilai prestasi dan entah bagaimana meningkatkannya.

Saya akan memberitahu anda cara menggunakan statistik secara berkesan untuk menyelesaikan pelbagai masalah yang anda ada atau mungkin ada.

Apa yang tidak akan ada dalam laporan? Dalam laporan itu, saya tidak akan menyentuh statistik penjadual, kerana. ini adalah topik yang berasingan untuk laporan berasingan tentang cara data disimpan dalam pangkalan data dan cara perancang pertanyaan mendapat idea tentang ciri kualitatif dan kuantitatif data ini.

Dan tidak akan ada ulasan alat, saya tidak akan membandingkan satu produk dengan yang lain. Tidak akan ada pengiklanan. Jom lepaskan.

Saya ingin menunjukkan kepada anda bahawa menggunakan statistik adalah berguna. Ia adalah perlu. Gunakannya tanpa rasa takut. Apa yang kita perlukan ialah SQL biasa dan pengetahuan asas tentang SQL.

Dan kita akan bercakap tentang statistik mana yang harus dipilih untuk menyelesaikan masalah.

Jika kita melihat PostgreSQL dan menjalankan arahan pada sistem pengendalian untuk melihat proses, kita akan melihat "kotak hitam". Kita akan melihat beberapa proses yang melakukan sesuatu, dan dengan nama kita boleh bayangkan secara kasar apa yang mereka lakukan di sana, apa yang mereka lakukan. Tetapi, sebenarnya, ini adalah kotak hitam, kita tidak boleh melihat ke dalam.

Kita boleh melihat beban CPU masuk top, kita boleh melihat penggunaan memori oleh beberapa utiliti sistem, tetapi kita tidak akan dapat melihat ke dalam PostgreSQL. Untuk ini kita memerlukan alat lain.

Dan meneruskan lebih jauh, saya akan memberitahu anda di mana masa dibelanjakan. Jika kita mewakili PostgreSQL dalam bentuk skema sedemikian, maka ia akan menjadi mungkin untuk menjawab di mana masa dibelanjakan. Ini adalah dua perkara: ia ialah pemprosesan permintaan klien daripada aplikasi dan tugas latar belakang yang PostgreSQL lakukan untuk memastikan ia berjalan.

Jika kita mula melihat di sudut kiri atas, kita dapat melihat bagaimana permintaan pelanggan diproses. Permintaan datang dari aplikasi dan sesi pelanggan dibuka untuk kerja selanjutnya. Permintaan diserahkan kepada penjadual. Perancang membina pelan pertanyaan. Menghantarnya lebih jauh untuk dilaksanakan. Terdapat beberapa jenis data blok I / O yang dikaitkan dengan jadual dan indeks. Data yang diperlukan dibaca dari cakera ke dalam memori di kawasan khas yang dipanggil "penampan kongsi". Keputusan pertanyaan, jika ia adalah kemas kini, pemadaman, direkodkan dalam log transaksi dalam WAL. Sesetengah maklumat statistik dimasukkan ke dalam log atau pengumpul statistik. Dan hasil permintaan diberikan semula kepada pelanggan. Selepas itu, pelanggan boleh mengulangi segala-galanya dengan permintaan baharu.

Apakah yang kita ada dengan tugas latar belakang dan proses latar belakang? Kami mempunyai beberapa proses yang memastikan pangkalan data berjalan dan berjalan seperti biasa. Proses-proses ini juga akan diliputi dalam laporan: ini ialah autovakum, pemeriksa, proses yang berkaitan dengan replikasi, penulis latar belakang. Saya akan menyentuh setiap daripada mereka semasa saya melaporkan.

Apakah masalah dengan statistik?

Banyak maklumat. PostgreSQL 9.4 menyediakan 109 metrik untuk melihat data statistik. Walau bagaimanapun, jika pangkalan data menyimpan banyak jadual, skema, pangkalan data, maka semua metrik ini perlu didarab dengan bilangan jadual, pangkalan data yang sepadan. Iaitu, terdapat lebih banyak maklumat. Dan ia sangat mudah untuk lemas di dalamnya.
Masalah seterusnya ialah statistik diwakili oleh pembilang. Jika kita melihat statistik ini, kita akan melihat kaunter yang sentiasa meningkat. Dan jika banyak masa telah berlalu sejak statistik ditetapkan semula, kita akan melihat berbilion nilai. Dan mereka tidak memberitahu kami apa-apa.
Tiada sejarah. Jika anda mengalami beberapa jenis kegagalan, sesuatu jatuh 15-30 minit yang lalu, anda tidak akan dapat menggunakan statistik dan melihat apa yang berlaku 15-30 minit yang lalu. Ini masalah.
Kekurangan alat terbina dalam PostgreSQL adalah masalah. Pembangun kernel tidak menyediakan sebarang utiliti. Mereka tidak mempunyai apa-apa seperti itu. Mereka hanya memberikan statistik dalam pangkalan data. Gunakannya, buat permintaan kepadanya, apa sahaja yang anda mahu, kemudian lakukannya.
Oleh kerana tiada alat terbina dalam PostgreSQL, ini menyebabkan masalah lain. Banyak alat pihak ketiga. Setiap syarikat yang mempunyai lebih kurang tangan langsung cuba menulis programnya sendiri. Dan akibatnya, komuniti mempunyai banyak alat yang boleh anda gunakan untuk bekerja dengan statistik. Dan dalam sesetengah alat terdapat beberapa ciri, dalam alat lain tiada ciri lain, atau terdapat beberapa ciri baharu. Dan situasi timbul bahawa anda perlu menggunakan dua, tiga, atau empat alat yang bertindih antara satu sama lain dan mempunyai fungsi yang berbeza. Ini sangat tidak menyenangkan.

Apa yang berikut daripada ini? Adalah penting untuk dapat mengambil statistik secara langsung supaya tidak bergantung pada program, atau entah bagaimana meningkatkan sendiri program ini: tambah beberapa fungsi untuk mendapatkan manfaat anda.

Dan anda memerlukan pengetahuan asas tentang SQL. Untuk mendapatkan beberapa data daripada statistik, anda perlu membuat pertanyaan SQL, iaitu anda perlu tahu cara pilih, sertai dibuat.

Statistik memberitahu kita beberapa perkara. Mereka boleh dibahagikan kepada kategori.

Kategori pertama ialah peristiwa yang berlaku dalam pangkalan data. Ini adalah apabila beberapa peristiwa berlaku dalam pangkalan data: pertanyaan, akses jadual, autovakum, komit, maka ini adalah semua peristiwa. Kaunter yang sepadan dengan acara ini dinaikkan. Dan kita boleh menjejaki peristiwa ini.
Kategori kedua ialah sifat objek seperti jadual, pangkalan data. Mereka mempunyai harta. Ini adalah saiz meja. Kita boleh menjejaki pertumbuhan jadual, pertumbuhan indeks. Kita boleh melihat perubahan dalam dinamik.
Dan kategori ketiga ialah masa yang dihabiskan untuk acara tersebut. Permintaan adalah acara. Ia mempunyai ukuran jangka masa tertentu. Bermula di sini, berakhir di sini. Kita boleh menjejakinya. Sama ada masa membaca blok dari cakera atau menulis. Perkara ini juga dijejaki.

Sumber statistik dibentangkan seperti berikut:

Dalam ingatan yang dikongsi (penampan dikongsi) terdapat segmen untuk meletakkan data statik di sana, terdapat juga pembilang yang sentiasa dinaikkan apabila peristiwa tertentu berlaku, atau beberapa detik timbul dalam operasi pangkalan data.
Semua kaunter ini tidak tersedia untuk pengguna dan tidak tersedia untuk pentadbir. Ini adalah perkara peringkat rendah. Untuk mengaksesnya, PostgreSQL menyediakan antara muka dalam bentuk fungsi SQL. Kami boleh membuat pilihan terpilih menggunakan fungsi ini dan mendapatkan beberapa jenis metrik (atau set metrik).
Walau bagaimanapun, ia tidak selalunya mudah untuk menggunakan fungsi ini, jadi fungsi adalah asas untuk pandangan (VIEW). Ini ialah jadual maya yang menyediakan statistik pada subsistem tertentu, atau pada beberapa set peristiwa dalam pangkalan data.
Paparan terbina dalam (VIEWS) ini ialah antara muka pengguna utama untuk bekerja dengan statistik. Mereka tersedia secara lalai tanpa sebarang tetapan tambahan, anda boleh segera menggunakannya, menonton, mengambil maklumat dari sana. Dan ada juga sumbangan. Sumbangan adalah rasmi. Anda boleh memasang pakej postgresql-contrib (contohnya, postgresql94-contrib), muatkan modul yang diperlukan dalam konfigurasi, tentukan parameter untuknya, mulakan semula PostgreSQL dan anda boleh menggunakannya. (Catatan. Bergantung pada pengedaran, dalam versi terbaru sumbangan pakej adalah sebahagian daripada pakej utama).
Dan terdapat sumbangan tidak rasmi. Mereka tidak dibekalkan dengan pengedaran PostgreSQL standard. Mereka mesti sama ada disusun atau dipasang sebagai perpustakaan. Pilihan boleh sangat berbeza, bergantung pada apa yang dihasilkan oleh pembangun sumbangan tidak rasmi ini.

Slaid ini menunjukkan semua paparan tersebut (VIEW) dan beberapa fungsi yang tersedia dalam PostgreSQL 9.4. Seperti yang kita lihat, terdapat banyak daripada mereka. Dan agak mudah untuk keliru jika anda mengalaminya buat kali pertama.

Namun, jika kita mengambil gambar sebelum ini Как тратится время на PostgreSQL dan serasi dengan senarai ini, kami mendapat gambar ini. Setiap paparan (VIEW), atau setiap fungsi, kita boleh gunakan untuk satu tujuan atau yang lain untuk mendapatkan statistik yang sesuai apabila kita menjalankan PostgreSQL. Dan kita sudah boleh mendapatkan beberapa maklumat tentang operasi subsistem.

Perkara pertama yang akan kita lihat ialah pg_stat_database. Seperti yang kita lihat, ini adalah representasi. Ia mengandungi banyak maklumat. Maklumat yang paling pelbagai. Dan ia memberikan pengetahuan yang sangat berguna tentang perkara yang kami lakukan dalam pangkalan data.

Apa yang boleh kita ambil dari sana? Mari kita mulakan dengan perkara yang paling mudah.

select
sum(blks_hit)*100/sum(blks_hit+blks_read) as hit_ratio
from pg_stat_database;

Perkara pertama yang boleh kita lihat ialah peratusan hit cache. Peratusan hit cache ialah metrik yang berguna. Ia membolehkan anda menganggarkan jumlah data yang diambil daripada cache penimbal yang dikongsi, dan jumlah yang dibaca daripada cakera.

Ia adalah jelas bahawa lebih banyak cache hit yang kita ada, lebih baik. Kami menilai metrik ini sebagai peratusan. Dan, sebagai contoh, jika kita mempunyai peratusan cache ini mencapai lebih daripada 90%, maka ini bagus. Jika ia jatuh di bawah 90%, maka kami tidak mempunyai ingatan yang mencukupi untuk menyimpan kepala panas data dalam ingatan. Dan untuk menggunakan data ini, PostgreSQL terpaksa mengakses cakera dan ini lebih perlahan berbanding jika data dibaca dari memori. Dan anda perlu memikirkan tentang meningkatkan memori: sama ada meningkatkan penimbal yang dikongsi, atau meningkatkan memori besi (RAM).

select
datname,
(xact_commit*100)/(xact_commit+xact_rollback) as c_ratio,
deadlocks, conflicts,
temp_file, pg_size_pretty(temp_bytes) as temp_size
from pg_stat_database;

Apa lagi yang boleh diambil daripada pembentangan ini? Anda boleh melihat anomali yang berlaku dalam pangkalan data. Apa yang ditunjukkan di sini? Terdapat komitmen, pemulangan semula, penciptaan fail sementara, saiznya, kebuntuan dan konflik.

Kami boleh menggunakan permintaan ini. SQL ini agak mudah. Dan kita boleh melihat data ini sendiri.

Dan berikut ialah nilai ambang. Kami melihat nisbah komitmen dan pemulangan semula. Komit ialah pengesahan transaksi yang berjaya. Rollback ialah rollback, iaitu transaksi melakukan beberapa kerja, menegangkan pangkalan data, mempertimbangkan sesuatu, dan kemudian kegagalan berlaku, dan hasil transaksi dibuang. i.e. bilangan rollback yang sentiasa meningkat adalah buruk. Dan anda harus mengelakkannya, dan mengedit kod supaya ini tidak berlaku.

Konflik berkaitan dengan replikasi. Dan mereka juga harus dielakkan. Jika anda mempunyai beberapa pertanyaan yang dilaksanakan pada replika dan konflik timbul, maka anda perlu menganalisis konflik ini dan melihat apa yang berlaku. Butiran boleh didapati dalam log. Dan selesaikan konflik supaya permintaan aplikasi berfungsi tanpa ralat.

Kebuntuan juga merupakan keadaan yang tidak baik. Apabila permintaan bersaing untuk mendapatkan sumber, satu permintaan mengakses satu sumber dan mengambil kunci, permintaan kedua mengakses sumber kedua dan turut mengambil kunci, dan kemudian kedua-dua permintaan mengakses sumber masing-masing dan disekat menunggu jiran melepaskan kunci. Ini juga merupakan situasi yang bermasalah. Ia perlu ditangani pada tahap menulis semula aplikasi dan menyerikan akses kepada sumber. Dan jika anda melihat bahawa kebuntuan anda sentiasa meningkat, anda perlu melihat butiran dalam log, menganalisis situasi yang telah timbul dan melihat apa masalahnya.

Fail sementara (temp_files) juga buruk. Apabila permintaan pengguna tidak mempunyai memori yang mencukupi untuk menampung data sementara operasi, ia mencipta fail pada cakera. Dan semua operasi yang dia boleh lakukan dalam penimbal sementara dalam ingatan, dia mula melaksanakan sudah pada cakera. Ia perlahan. Ini meningkatkan masa pelaksanaan pertanyaan. Dan pelanggan yang menghantar permintaan kepada PostgreSQL akan menerima respons sedikit kemudian. Jika semua operasi ini dilakukan dalam ingatan, Postgres akan bertindak balas dengan lebih pantas dan pelanggan akan menunggu lebih sedikit.

pg_stat_bgwriter - Pandangan ini menerangkan operasi dua subsistem latar belakang PostgreSQL: checkpointer и background writer.

Sebagai permulaan, mari kita menganalisis titik kawalan, yang dipanggil. checkpoints. Apakah pusat pemeriksaan? Pusat pemeriksaan ialah kedudukan dalam log transaksi yang menunjukkan bahawa semua perubahan data yang dilakukan dalam log berjaya disegerakkan dengan data pada cakera. Proses, bergantung pada beban kerja dan tetapan, boleh menjadi panjang dan kebanyakannya terdiri daripada menyegerakkan halaman kotor dalam penimbal kongsi dengan fail data pada cakera. Untuk apa itu? Jika PostgreSQL mengakses cakera sepanjang masa dan mengambil data dari sana, dan menulis data pada setiap akses, ia akan menjadi perlahan. Oleh itu, PostgreSQL mempunyai segmen memori, saiznya bergantung pada parameter dalam konfigurasi. Postgres memperuntukkan data operasi dalam memori ini untuk pemprosesan atau pertanyaan lanjut. Dalam kes permintaan perubahan data, ia diubah. Dan kami mendapat dua versi data. Satu dalam ingatan, satu lagi dalam cakera. Dan secara berkala anda perlu menyegerakkan data ini. Kami memerlukan apa yang diubah dalam memori untuk disegerakkan ke cakera. Ini memerlukan pusat pemeriksaan.

Checkpoint melalui penimbal yang dikongsi, menandakan halaman kotor yang mereka perlukan untuk checkpoint. Kemudian ia memulakan laluan kedua melalui penimbal yang dikongsi. Dan halaman yang ditandakan untuk checkpoint, dia sudah menyegerakkannya. Oleh itu, data telah disegerakkan dengan cakera.

Terdapat dua jenis titik kawalan. Satu pusat pemeriksaan dilaksanakan pada tamat masa. Pusat pemeriksaan ini berguna dan baik - checkpoint_timed. Dan terdapat pusat pemeriksaan atas permintaan - checkpoint required. Pusat pemeriksaan sedemikian berlaku apabila kita mempunyai rekod data yang sangat besar. Kami merekodkan banyak log transaksi. Dan PostgreSQL percaya bahawa ia perlu menyegerakkan semua ini secepat mungkin, membuat pusat pemeriksaan dan teruskan.

Dan jika anda melihat statistik pg_stat_bgwriter dan lihat apa yang anda ada checkpoint_req jauh lebih besar daripada checkpoint_timed, maka ini buruk. Kenapa teruk? Ini bermakna PostgreSQL berada di bawah tekanan berterusan apabila ia perlu menulis data ke cakera. Pusat pemeriksaan mengikut tamat masa kurang tertekan dan dilaksanakan mengikut jadual dalaman dan, seolah-olah, dipanjangkan dari semasa ke semasa. PostgreSQL mempunyai keupayaan untuk berhenti seketika dalam kerja dan tidak menegangkan subsistem cakera. Ini berguna untuk PostgreSQL. Dan permintaan yang dilaksanakan semasa pusat pemeriksaan tidak akan mengalami tekanan daripada fakta bahawa subsistem cakera sibuk.

Dan terdapat tiga parameter untuk melaraskan pusat pemeriksaan:

сheckpoint_segments.
сheckpoint_timeout.
сheckpoint_competion_target.

Mereka membenarkan anda mengawal operasi titik kawalan. Tetapi saya tidak akan memikirkan mereka. Pengaruh mereka adalah isu yang berasingan.

Amaran: Versi 9.4 yang dipertimbangkan dalam laporan tidak lagi relevan. Dalam versi moden PostgreSQL, parameter checkpoint_segments digantikan dengan parameter min_wal_size и max_wal_size.

Subsistem seterusnya ialah penulis latar belakang − background writer. Apa yang dia buat? Ia berjalan secara berterusan dalam gelung yang tidak berkesudahan. Ia mengimbas halaman ke dalam penimbal yang dikongsi dan membuang halaman kotor yang ditemuinya ke cakera. Dengan cara ini, ia membantu petugas pemeriksaan untuk melakukan lebih sedikit kerja semasa pemeriksaan.

Apa lagi yang dia perlukan? Ia menyediakan keperluan untuk halaman bersih dalam penimbal kongsi jika ia tiba-tiba diperlukan (dalam kuantiti yang banyak dan serta-merta) untuk menampung data. Katakan situasi timbul apabila permintaan memerlukan halaman bersih dan halaman tersebut sudah berada dalam penimbal kongsi. Postgres backend dia hanya mengambil dan menggunakannya, dia tidak perlu membersihkan apa-apa sendiri. Tetapi jika tiba-tiba tiada halaman sedemikian, bahagian belakang berhenti sebentar dan mula mencari halaman untuk mengepamnya ke cakera dan membawanya untuk keperluannya sendiri - yang memberi kesan negatif pada masa permintaan yang sedang dilaksanakan. Jika anda melihat bahawa anda mempunyai parameter maxwritten_clean besar, ini bermakna penulis latar belakang tidak menjalankan tugasnya dan anda perlu meningkatkan parameter bgwriter_lru_maxpagessupaya dia boleh melakukan lebih banyak kerja dalam satu kitaran, mengosongkan lebih banyak halaman.

Dan satu lagi penunjuk yang sangat berguna ialah buffers_backend_fsync. Bahagian belakang tidak melakukan fsync kerana ia perlahan. Mereka menghantar fsync ke atas penunjuk semak tindanan IO. Checkpointer mempunyai baris gilir sendiri, ia secara berkala memproses fsync dan menyegerakkan halaman dalam memori dengan fail pada cakera. Jika baris gilir pemeriksa adalah besar dan penuh, maka hujung belakang terpaksa melakukan fsync sendiri dan ini memperlahankan bahagian belakang, iaitu pelanggan akan menerima respons lewat daripada yang boleh. Jika anda melihat bahawa anda mempunyai nilai ini lebih besar daripada sifar, maka ini sudah menjadi masalah dan anda perlu memberi perhatian kepada tetapan penulis latar belakang dan juga menilai prestasi subsistem cakera.

Amaran: _Teks berikut menerangkan pandangan statistik yang dikaitkan dengan replikasi. Kebanyakan nama paparan dan fungsi telah dinamakan semula dalam Postgres 10. Intipati nama semula adalah untuk menggantikan xlog pada wal и location pada lsn dalam nama fungsi/pandangan, dsb. Contoh khusus, fungsi pg_xlog_location_diff() telah dinamakan semula kepada pg_wal_lsn_diff()._

Kami juga mempunyai banyak di sini. Tetapi kami hanya memerlukan item yang berkaitan dengan lokasi.

Jika kita melihat bahawa semua nilai adalah sama, maka ini adalah ideal dan replika tidak ketinggalan di belakang tuan.

Kedudukan perenambelasan di sini ialah kedudukan dalam log transaksi. Ia sentiasa meningkat jika terdapat beberapa aktiviti dalam pangkalan data: memasukkan, memadam, dll.

сколько записано xlog в байтах
$ select
pg_xlog_location_diff(pg_current_xlog_location(),'0/00000000');
лаг репликации в байтах
$ select
client_addr,
pg_xlog_location_diff(pg_current_xlog_location(), replay_location)
from pg_stat_replication;
лаг репликации в секундах
$ select
extract(epoch from now() - pg_last_xact_replay_timestamp());

Jika perkara ini berbeza, maka terdapat beberapa jenis ketinggalan. Lag ialah lag replika daripada master, iaitu data berbeza antara pelayan.

Terdapat tiga sebab kelewatan:

Ia adalah subsistem cakera yang tidak dapat mengendalikan penulisan penyegerakan fail.
Ini adalah kemungkinan ralat rangkaian, atau beban rangkaian, apabila data tidak mempunyai masa untuk mencapai replika dan ia tidak dapat menghasilkannya semula.
Dan pemproses. Pemproses adalah kes yang sangat jarang berlaku. Dan saya telah melihatnya dua atau tiga kali, tetapi itu juga boleh berlaku.

Dan berikut ialah tiga pertanyaan yang membolehkan kami menggunakan statistik. Kami boleh menganggarkan jumlah yang direkodkan dalam log transaksi kami. Terdapat fungsi sedemikian pg_xlog_location_diff dan kita boleh menganggarkan ketinggalan replikasi dalam bait dan saat. Kami juga menggunakan nilai daripada pandangan ini (VIEW) untuk ini.

Nota: _Daripada pg_xlog_locationdiff(), anda boleh menggunakan operator tolak dan tolak satu lokasi daripada lokasi lain. Selesa.

Dengan lag, iaitu dalam beberapa saat, ada satu saat. Jika tiada aktiviti pada master, transaksi itu berlaku kira-kira 15 minit yang lalu dan tiada aktiviti, dan jika kita melihat ketinggalan ini pada replika, kita akan melihat ketinggalan selama 15 minit. Ini patut diingati. Dan ia boleh menyebabkan pingsan apabila anda menonton ketinggalan ini.

pg_stat_all_tables ialah satu lagi paparan berguna. Ia menunjukkan statistik pada jadual. Apabila kita mempunyai jadual dalam pangkalan data, terdapat beberapa aktiviti dengannya, beberapa tindakan, kita boleh mendapatkan maklumat ini dari pandangan ini.

select
relname,
pg_size_pretty(pg_relation_size(relname::regclass)) as size,
seq_scan, seq_tup_read,
seq_scan / seq_tup_read as seq_tup_avg
from pg_stat_user_tables
where seq_tup_read > 0 order by 3,4 desc limit 5;

Perkara pertama yang boleh kita lihat ialah imbasan jadual berurutan. Nombor itu sendiri selepas petikan ini tidak semestinya buruk dan tidak menunjukkan bahawa kita perlu melakukan sesuatu sudah.

Walau bagaimanapun, terdapat metrik kedua - seq_tup_read. Ini ialah bilangan baris yang dikembalikan daripada imbasan berjujukan. Jika bilangan purata melebihi 1, 000, 10, 000, maka ini sudah menjadi penunjuk bahawa anda mungkin perlu membina indeks di suatu tempat supaya akses adalah mengikut indeks, atau mungkin untuk mengoptimumkan pertanyaan yang menggunakan imbasan berurutan sedemikian supaya ini tidak berlaku. was.

Contoh mudah - katakan permintaan dengan OFFSET dan LIMIT yang besar adalah berbaloi. Sebagai contoh, 100 baris dalam jadual diimbas dan selepas itu 000 baris yang diperlukan diambil, dan baris yang diimbas sebelumnya dibuang. Ini juga kes yang teruk. Dan permintaan sedemikian perlu dioptimumkan. Dan berikut adalah pertanyaan SQL yang mudah di mana anda boleh melihatnya dan menilai nombor yang diterima.

select
relname,
pg_size_pretty(pg_total_relation_size(relname::regclass)) as
full_size,
pg_size_pretty(pg_relation_size(relname::regclass)) as
table_size,
pg_size_pretty(pg_total_relation_size(relname::regclass) -
pg_relation_size(relname::regclass)) as index_size
from pg_stat_user_tables
order by pg_total_relation_size(relname::regclass) desc limit 10;

Saiz jadual juga boleh diperoleh menggunakan jadual ini dan menggunakan fungsi tambahan pg_total_relation_size(), pg_relation_size().

Secara umum, terdapat metacommands dt и di, yang boleh anda gunakan dalam PSQL dan juga lihat saiz jadual dan indeks.

Walau bagaimanapun, penggunaan fungsi membantu kita melihat saiz jadual, walaupun mengambil kira indeks, atau tanpa mengambil kira indeks, dan sudah membuat beberapa anggaran berdasarkan pertumbuhan pangkalan data, iaitu bagaimana ia berkembang bersama kita, dengan berapa keamatan, dan sudah membuat beberapa kesimpulan tentang pengoptimuman saiz.

Aktiviti tulis. Apakah rekod? Mari kita lihat operasi UPDATE – operasi mengemas kini baris dalam jadual. Sebenarnya, kemas kini ialah dua operasi (atau lebih). Ini sedang memasukkan versi baris baharu dan menandakan versi baris lama sebagai usang. Kemudian, autovakum akan datang dan membersihkan versi lapuk garisan ini, tandakan tempat ini sebagai tersedia untuk digunakan semula.

Selain itu, kemas kini bukan sekadar mengemas kini jadual. Ia masih kemas kini indeks. Jika anda mempunyai banyak indeks pada jadual, maka dengan kemas kini, semua indeks di mana medan dikemas kini dalam pertanyaan mengambil bahagian juga perlu dikemas kini. Indeks ini juga akan mempunyai versi baris usang yang perlu dibersihkan.

select
s.relname,
pg_size_pretty(pg_relation_size(relid)),
coalesce(n_tup_ins,0) + 2 * coalesce(n_tup_upd,0) -
coalesce(n_tup_hot_upd,0) + coalesce(n_tup_del,0) AS total_writes,
(coalesce(n_tup_hot_upd,0)::float * 100 / (case when n_tup_upd > 0
then n_tup_upd else 1 end)::float)::numeric(10,2) AS hot_rate,
(select v[1] FROM regexp_matches(reloptions::text,E'fillfactor=(\d+)') as
r(v) limit 1) AS fillfactor
from pg_stat_all_tables s
join pg_class c ON c.oid=relid
order by total_writes desc limit 50;

Dan disebabkan reka bentuknya, KEMASKINI adalah operasi kelas berat. Tetapi mereka boleh dipermudahkan. makan hot updates. Mereka muncul dalam PostgreSQL versi 8.3. Dan apakah ini? Ini ialah kemas kini ringan yang tidak menyebabkan indeks dibina semula. Iaitu, kami mengemas kini rekod, tetapi hanya rekod dalam halaman (yang tergolong dalam jadual) telah dikemas kini, dan indeks masih menunjuk ke rekod yang sama dalam halaman. Terdapat sedikit logik kerja yang menarik, apabila vakum datang, maka ia mempunyai rantai ini hot membina semula dan semuanya terus berfungsi tanpa mengemas kini indeks, dan semuanya berlaku dengan kurang pembaziran sumber.

Dan apabila anda mempunyai n_tup_hot_upd besar, ia sangat bagus. Ini bermakna kemas kini ringan diguna pakai dan ini lebih murah untuk kami dari segi sumber dan semuanya baik-baik saja.

ALTER TABLE table_name SET (fillfactor = 70);

Bagaimana untuk meningkatkan volum hot updateov? Kita boleh guna fillfactor. Ia menentukan saiz ruang kosong yang dikhaskan apabila mengisi halaman dalam jadual menggunakan INSERTs. Apabila sisipan pergi ke meja, mereka mengisi halaman sepenuhnya, jangan biarkan ruang kosong di dalamnya. Kemudian halaman baharu diserlahkan. Data diisi semula. Dan ini adalah tingkah laku lalai, fillfactor = 100%.

Kita boleh menetapkan fillfactor kepada 70%. Iaitu, dengan sisipan, halaman baharu telah diperuntukkan, tetapi hanya 70% halaman telah diisi. Dan kami mempunyai 30% lagi dalam simpanan. Apabila anda perlu melakukan kemas kini, kemungkinan besar ia akan berlaku pada halaman yang sama dan versi baris baharu akan muat pada halaman yang sama. Dan hot_update akan dilakukan. Ini menjadikannya lebih mudah untuk menulis pada jadual.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Barisan autovakum. Autovacuum ialah subsistem yang mana terdapat sedikit statistik dalam PostgreSQL. Kita hanya boleh melihat dalam jadual dalam pg_stat_activity berapa banyak vakum yang kita ada pada masa ini. Walau bagaimanapun, adalah sangat sukar untuk memahami berapa banyak jadual dalam baris gilir yang ada semasa bergerak.

Nota: _Sejak Postgres 10, keadaan dengan menjejaki vakum vakum telah banyak bertambah baik - paparan pg_stat_progress telah munculvakum, yang sangat memudahkan isu pemantauan autovakum.

Kita boleh menggunakan pertanyaan ringkas ini. Dan kita boleh lihat bila vakum perlu dibuat. Tetapi, bagaimana dan bila vakum harus bermula? Ini adalah versi lama rentetan yang saya bincangkan sebelum ini. Kemas kini telah berlaku, versi baharu baris telah dimasukkan. Versi rentetan yang usang telah muncul. Jadual pg_stat_user_tables terdapat parameter sedemikian n_dead_tup. Ia menunjukkan bilangan baris "mati". Dan sebaik sahaja bilangan baris mati telah menjadi lebih daripada ambang tertentu, autovakum akan datang ke meja.

Dan bagaimanakah ambang ini dikira? Ini adalah peratusan yang sangat khusus daripada jumlah bilangan baris dalam jadual. Terdapat parameter autovacuum_vacuum_scale_factor. Ia mentakrifkan peratusan. Katakan 10% + terdapat ambang asas tambahan sebanyak 50 baris. Dan apa yang berlaku? Apabila kami mempunyai lebih banyak baris mati daripada "10% + 50" daripada semua baris dalam jadual, kami meletakkan jadual pada autovakum.

select c.relname,
current_setting('autovacuum_vacuum_threshold') as av_base_thresh,
current_setting('autovacuum_vacuum_scale_factor') as av_scale_factor,
(current_setting('autovacuum_vacuum_threshold')::int +
(current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples))
as av_thresh,
s.n_dead_tup
from pg_stat_user_tables s join pg_class c ON s.relname = c.relname
where s.n_dead_tup > (current_setting('autovacuum_vacuum_threshold')::int
+ (current_setting('autovacuum_vacuum_scale_factor')::float * c.reltuples));

Walau bagaimanapun, terdapat satu perkara. Ambang asas untuk parameter av_base_thresh и av_scale_factor boleh ditugaskan secara individu. Dan, dengan itu, ambang tidak akan global, tetapi individu untuk jadual. Oleh itu, untuk mengira, di sana anda perlu menggunakan helah dan helah. Dan jika anda berminat, anda boleh melihat pengalaman rakan sekerja kami dari Avito (pautan pada slaid tidak sah dan telah dikemas kini dalam teks).

Mereka menulis untuk pemalam muninyang mengambil kira perkara-perkara ini. Terdapat alas kaki pada dua helai. Tetapi dia berfikir dengan betul dan agak berkesan membolehkan kita menilai di mana kita memerlukan banyak vakum untuk jadual di mana terdapat sedikit.

Apa yang boleh kita lakukan mengenainya? Jika kita beratur panjang dan autovakum tidak dapat mengatasinya, maka kita boleh menambah bilangan pekerja vakum, atau hanya menjadikan vakum lebih agresifsupaya ia mencetuskan lebih awal, memproses jadual dalam kepingan kecil. Dan dengan itu barisan akan berkurangan. - Perkara utama di sini adalah untuk memantau beban pada cakera, kerana. Perkara vakum tidak percuma, walaupun dengan kemunculan peranti SSD / NVMe, masalahnya menjadi kurang ketara.

pg_stat_all_indexes ialah statistik pada indeks. Dia tidak besar. Dan kita boleh mendapatkan maklumat tentang penggunaan indeks daripadanya. Dan sebagai contoh, kita boleh menentukan indeks yang kita ada tambahan.

Seperti yang saya telah katakan, kemas kini bukan sahaja mengemas kini jadual, ia juga mengemas kini indeks. Oleh itu, jika kita mempunyai banyak indeks pada jadual, maka apabila mengemas kini baris dalam jadual, indeks medan yang diindeks juga perlu dikemas kini, dan jika kita mempunyai indeks yang tidak digunakan yang tidak terdapat imbasan indeks, maka ia bergantung kepada kita sebagai pemberat. Dan anda perlu menyingkirkan mereka. Untuk ini kita memerlukan medan idx_scan. Kami hanya melihat bilangan imbasan indeks. Jika indeks mempunyai imbasan sifar dalam tempoh penyimpanan statistik yang agak lama (sekurang-kurangnya 2-3 minggu), maka kemungkinan besar ini adalah indeks yang tidak baik, kita perlu menyingkirkannya.

Nota: Apabila mencari indeks yang tidak digunakan dalam kes kluster replikasi penstriman, anda perlu menyemak semua nod kluster, kerana statistik bukan global, dan jika indeks tidak digunakan pada induk, maka ia boleh digunakan pada replika (jika ada beban).

Dua pautan:

https://github.com/dataegret/pg-utils/blob/master/sql/low_used_indexes.sql

http://www.databasesoup.com/2014/05/new-finding-unused-indexes-query.html

Ini adalah contoh pertanyaan yang lebih lanjut tentang cara mencari indeks yang tidak digunakan.

Pautan kedua adalah pertanyaan yang agak menarik. Terdapat logik yang sangat tidak remeh di dalamnya. Saya mengesyorkannya untuk semakan.

Apa lagi yang harus disimpulkan oleh indeks?

Indeks yang tidak digunakan adalah buruk.
Mereka mengambil ruang.
Perlahankan operasi kemas kini.
Kerja tambahan untuk vakum.

Jika kami mengalih keluar indeks yang tidak digunakan, maka kami hanya akan menjadikan pangkalan data lebih baik.

Pandangan seterusnya ialah pg_stat_activity. Ini adalah analog utiliti ps, hanya dalam PostgreSQL. Jika ps'ohm anda menonton proses dalam sistem pengendalian, kemudian pg_stat_activity akan menunjukkan kepada anda aktiviti di dalam PostgreSQL.

Apa yang boleh kita ambil dari sana?

select
count(*)*100/(select current_setting('max_connections')::int)
from pg_stat_activity;

Kita boleh melihat keseluruhan aktiviti yang berlaku dalam pangkalan data. Kita boleh membuat penempatan baharu. Segala-galanya meletup di sana, sambungan baru tidak diterima, ralat mencurah-curah dalam aplikasi.

select
client_addr, usename, datname, count(*)
from pg_stat_activity group by 1,2,3 order by 4 desc;

Kami boleh menjalankan pertanyaan seperti ini dan melihat jumlah peratusan sambungan berbanding dengan had sambungan maksimum dan melihat siapa kami mempunyai paling banyak sambungan. Dan dalam kes yang diberikan ini, kita melihat pengguna itu cron_role membuka 508 sambungan. Dan sesuatu berlaku kepadanya. Anda perlu berurusan dengannya dan lihat. Dan agak mungkin bahawa ini adalah sejenis bilangan sambungan yang tidak normal.

Jika kita mempunyai beban OLTP, pertanyaan hendaklah pantas, sangat pantas dan tidak perlu ada pertanyaan panjang. Walau bagaimanapun, jika terdapat permintaan yang panjang, maka dalam jangka pendek tidak ada yang perlu dibimbangkan, tetapi dalam jangka masa panjang, pertanyaan panjang merosakkan pangkalan data, mereka meningkatkan kesan kembung jadual apabila pemecahan jadual berlaku. Kedua-dua pertanyaan bloat dan panjang perlu dilupuskan.

select
client_addr, usename, datname,
clock_timestamp() - xact_start as xact_age,
clock_timestamp() - query_start as query_age,
query
from pg_stat_activity order by xact_start, query_start;

Sila ambil perhatian: dengan permintaan sedemikian, kami boleh menentukan permintaan dan transaksi yang panjang. Kami menggunakan fungsi tersebut clock_timestamp() untuk menentukan masa bekerja. Permintaan panjang yang kami temui, kami boleh mengingatinya, melaksanakannya explain, lihat rancangan dan entah bagaimana mengoptimumkan. Kami merakam permintaan lama semasa dan terus hidup.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Urus niaga buruk adalah terbiar dalam transaksi dan terbiar dalam transaksi (dibatalkan).

Apakah maksudnya? Transaksi mempunyai beberapa keadaan. Dan salah satu negeri ini boleh diambil pada bila-bila masa. Terdapat medan untuk menentukan keadaan state dalam pandangan ini. Dan kita menggunakannya untuk menentukan negeri.

select * from pg_stat_activity where state in
('idle in transaction', 'idle in transaction (aborted)';

Dan, seperti yang saya katakan di atas, kedua-dua negeri ini terbiar dalam transaksi dan terbiar dalam transaksi (digugurkan) adalah buruk. Apa ini? Pada masa inilah aplikasi membuka transaksi, melakukan beberapa tindakan dan menjalankan perniagaannya. Transaksi tetap terbuka. Ia tergantung, tiada apa-apa yang berlaku di dalamnya, ia memerlukan sambungan, mengunci pada baris yang diubah dan bahkan berpotensi meningkatkan bloat jadual lain, disebabkan oleh seni bina enjin transaksi Postrges. Dan transaksi sedemikian juga harus ditembak, kerana ia berbahaya secara umum, dalam apa jua keadaan.

Jika anda melihat bahawa anda mempunyai lebih daripada 5-10-20 daripadanya dalam pangkalan data anda, maka anda perlu bimbang dan mula melakukan sesuatu dengan mereka.

Di sini kita juga gunakan untuk masa pengiraan clock_timestamp(). Kami merakam transaksi, kami mengoptimumkan aplikasi.

Seperti yang saya katakan di atas, kunci ialah apabila dua atau lebih transaksi bersaing untuk satu atau sekumpulan sumber. Untuk ini kami mempunyai bidang waiting dengan nilai boolean true atau false.

Benar - ini bermakna bahawa proses sedang menunggu, sesuatu perlu dilakukan. Apabila proses sedang menunggu, maka klien yang memulakan proses itu juga sedang menunggu. Pelanggan dalam penyemak imbas duduk dan juga menunggu.

Amaran: _Bermula dari Postgres 9.6, medan waiting dialih keluar dan digantikan dengan dua lagi medan bermaklumat wait_event_type и wait_event._

Apa yang perlu dilakukan? Jika anda melihat kebenaran untuk masa yang lama, maka anda harus menyingkirkan permintaan tersebut. Kami hanya menembak transaksi sedemikian. Kami menulis kepada pembangun apa yang perlu dioptimumkan entah bagaimana supaya tiada perlumbaan untuk mendapatkan sumber. Dan kemudian pemaju mengoptimumkan aplikasi supaya ini tidak berlaku.

Dan yang melampau, tetapi pada masa yang sama berpotensi tidak membawa maut kes berlakunya kebuntuan. Dua urus niaga telah mengemas kini dua sumber, kemudian mereka mengaksesnya semula, sudah kepada sumber yang bertentangan. PostgreSQL dalam kes ini mengambil dan melancarkan transaksi itu sendiri supaya yang lain boleh terus berfungsi. Ini adalah keadaan buntu dan dia tidak memahami dirinya sendiri. Oleh itu, PostgreSQL terpaksa mengambil langkah yang melampau.

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/c4_06_show_locked_queries.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_95.sql

https://github.com/lesovsky/uber-scripts/blob/master/postgresql/sql/show_locked_queries_96.sql

http://big-elephants.com/2013-09/exploring-query-locks-in-postgres/

Dan berikut ialah dua pertanyaan yang membolehkan anda menjejak kunci. Kami menggunakan pandangan pg_locks, yang membolehkan anda menjejak kunci berat.

Dan pautan pertama ialah teks permintaan itu sendiri. Ia agak panjang.

Dan pautan kedua ialah artikel mengenai kunci. Ia berguna untuk dibaca, ia sangat menarik.

Jadi apa yang kita nampak? Kami melihat dua permintaan. Transaksi dengan ALTER TABLE adalah transaksi menyekat. Ia bermula, tetapi tidak berakhir, dan aplikasi yang menyiarkan transaksi ini melakukan perkara lain di suatu tempat. Dan permintaan kedua ialah kemas kini. Ia menunggu jadual alter selesai sebelum meneruskan kerjanya.

Ini adalah bagaimana kita boleh mengetahui siapa yang mengurung siapa, siapa yang menahan siapa, dan kita boleh menangani perkara ini dengan lebih lanjut.

Modul seterusnya ialah pg_stat_statements. Seperti yang saya katakan, ia adalah modul. Untuk menggunakannya, anda perlu memuatkan perpustakaannya dalam konfigurasi, mulakan semula PostgreSQL, pasang modul (dengan satu arahan), dan kemudian kami akan mempunyai paparan baharu.

Cреднее время запроса в милисекундах
$ select (sum(total_time) / sum(calls))::numeric(6,3)
from pg_stat_statements;

Самые активно пишущие (в shared_buffers) запросы
$ select query, shared_blks_dirtied
from pg_stat_statements
where shared_blks_dirtied > 0 order by 2 desc;

Apa yang boleh kita ambil dari sana? Jika kita bercakap tentang perkara mudah, kita boleh mengambil purata masa pelaksanaan pertanyaan. Masa semakin berkembang, yang bermaksud bahawa PostgreSQL bertindak balas dengan perlahan dan sesuatu perlu dilakukan.

Kita boleh melihat transaksi penulisan paling aktif dalam pangkalan data yang menukar data dalam penimbal kongsi. Lihat siapa yang mengemas kini atau memadam data di sana.

Dan kita hanya boleh melihat statistik yang berbeza untuk permintaan ini.

https://github.com/dataegret/pg-utils/blob/master/sql/global_reports/query_stat_total.sql

Kami pg_stat_statements digunakan untuk membina laporan. Kami menetapkan semula statistik sekali sehari. Jom kumpulkan. Sebelum menetapkan semula statistik lain kali, kami membina laporan. Berikut adalah pautan kepada laporan tersebut. Anda boleh menontonnya.

Apa yang kita buat? Kami mengira statistik keseluruhan untuk semua permintaan. Kemudian, untuk setiap pertanyaan, kami mengira sumbangan individunya kepada statistik keseluruhan ini.

Dan apa yang boleh kita lihat? Kita boleh melihat jumlah masa pelaksanaan semua permintaan jenis tertentu terhadap latar belakang semua permintaan lain. Kita boleh melihat penggunaan CPU dan I/O berhubung dengan gambaran keseluruhan. Dan sudah untuk mengoptimumkan permintaan ini. Kami sedang membina pertanyaan teratas berdasarkan laporan ini dan sudah mula memikirkan perkara yang perlu dioptimumkan.

Apa yang kita ada di belakang tabir? Masih ada beberapa penyertaan yang saya tidak pertimbangkan, kerana masa adalah terhad.

Terdapat pgstattuple juga merupakan modul tambahan daripada pakej sumbangan standard. Ia membolehkan anda menilai bloat meja, dipanggil. pemecahan jadual. Dan jika pemecahan itu besar, anda perlu mengeluarkannya, gunakan alat yang berbeza. Dan fungsi pgstattuple berfungsi untuk masa yang lama. Dan lebih banyak jadual, lebih lama ia akan berfungsi.

Sumbangan seterusnya ialah pg_buffercache. Ia membolehkan anda memeriksa penimbal yang dikongsi: seberapa intensif dan untuk mana halaman penimbal jadual digunakan. Dan ia hanya membolehkan anda melihat penimbal yang dikongsi dan menilai apa yang berlaku di sana.

Modul seterusnya ialah pgfincore. Ia membolehkan anda melakukan operasi jadual peringkat rendah melalui panggilan sistem mincore(), iaitu ia membolehkan anda memuatkan jadual ke dalam penimbal kongsi atau memunggahnya. Dan ia membolehkan, antara lain, untuk memeriksa cache halaman sistem pengendalian, iaitu, berapa banyak jadual yang diduduki dalam cache halaman, dalam penimbal yang dikongsi, dan hanya membolehkan anda menilai beban di atas meja.

Modul seterusnya ialah pg_stat_kcache. Ia juga menggunakan panggilan sistem getrusage(). Dan ia melaksanakannya sebelum dan selepas permintaan itu dilaksanakan. Dan dalam statistik yang diperoleh, ia membolehkan kami menganggarkan berapa banyak permintaan kami dibelanjakan pada cakera I / O, iaitu, operasi dengan sistem fail dan melihat penggunaan pemproses. Walau bagaimanapun, modul ini masih muda (khe-khe) dan untuk kerjanya ia memerlukan PostgreSQL 9.4 dan pg_stat_statements, yang saya nyatakan sebelum ini.

Keupayaan untuk menggunakan statistik berguna. Anda tidak memerlukan perisian pihak ketiga. Anda boleh melihat, melihat, melakukan sesuatu, melakukan.
Menggunakan statistik adalah mudah, ia adalah SQL biasa. Anda mengumpulkan permintaan, menyusunnya, menghantarnya, melihatnya.
Statistik membantu menjawab soalan. Jika anda mempunyai soalan, anda beralih kepada statistik - lihat, buat kesimpulan, analisis hasilnya.
Dan percubaan. Banyak permintaan, banyak data. Anda sentiasa boleh mengoptimumkan beberapa pertanyaan sedia ada. Anda boleh membuat versi permintaan anda sendiri yang lebih sesuai dengan anda daripada yang asal dan menggunakannya.