Apa yang dilakukan grep saat tidak menjalankan CPU?

Saat mencari kecocokan dengan grep, saya sering melihat bahwa pencarian berikutnya memakan waktu jauh lebih sedikit daripada yang pertama - misalnya 25s vs 2s. Jelas, itu bukan dengan menggunakan kembali struktur data dari jalankan terakhir - yang seharusnya sudah dialokasikan. Menjalankan timeperintah grep, saya perhatikan fenomena menarik:

real    24m36.561s
user    1m20.080s
sys     0m7.230s

Kemana sisa waktu pergi? Adakah yang bisa saya lakukan untuk membuatnya berlari cepat setiap saat? (mis. meminta proses lain membaca file, sebelum grepmencarinya.)

grep performance

— Alex
sumber

Jawaban:

Ini cukup sering dikaitkan dengan halaman cache .

Pertama kali, data harus dibaca (secara fisik) dari disk.

Kali kedua (untuk file yang tidak terlalu besar) kemungkinan akan duduk di cache halaman.

Jadi Anda bisa mengeluarkan perintah pertama seperti cat (1) untuk membawa file (tidak terlalu besar) ke cache halaman (yaitu dalam RAM), kemudian grep kedua (1) (atau program apa pun yang membaca file) umumnya akan berjalan lebih cepat .

^{(namun, data masih perlu dibaca dari disk pada suatu waktu)}

Lihat juga (kadang-kadang berguna dalam program aplikasi Anda, tetapi praktis jarang) readahead (2) & posix_fadvise (2) dan mungkin madvise (2) & sync (2) & fsync (2) dll ....

Baca juga LinuxAteMyRAM .

BTW, inilah sebabnya mengapa direkomendasikan, ketika melakukan benchmark program, untuk menjalankannya beberapa kali. Juga, inilah sebabnya mengapa mungkin berguna untuk membeli lebih banyak RAM (bahkan jika Anda tidak menjalankan program menggunakan semua itu untuk data mereka).

Jika Anda ingin lebih memahami, baca beberapa buku seperti misalnya Sistem Operasi: Tiga Potong Mudah

— Basile Starynkevitch
sumber

Jadi, TL;DRjawabannya adalah "[blok menunggu] I / O".

— mgarciaisaia

@PaulDraper Tidak juga :) cat+ grepmasih akan memakan waktu lebih lama daripada grepsendirian.

— chepner

@ chepner Kecuali Anda dapat melakukan multithread dan menggunakannya catsebagai pre-fetch murah saat Anda melakukan hal lain, sebagai persiapan untuk grepminat.

— hBy2Py

@MarkKCowan: Kucing cantik! :-) ⁠

— G-Man Mengatakan 'Reinstate Monica'

@ G-Man: Anda juga dapat mengganti dua cats dengan tacefek yang sama dan penggunaan RAM yang lebih tinggi: D Atau semua kucing dengan tac

— Mark K Cowan

-1

Dalam lingkungan penyimpanan jaringan, ada juga penundaan yang relatif signifikan ketika Anda pertama kali mengakses file yang berada di "filer" yang terpisah dari server. Setelah file itu diakses di server, itu akan di-cache secara lokal dan selanjutnya akses ke data akan jauh lebih cepat.

Berikut ini eksperimen yang hanya menghitung checksum dari data file - bukan grep. Doa pertama lambat, dan yang berikutnya cepat.

> du -Dh file_348m
348M    file_348m

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.60user 0.15system 0:03.02elapsed 25%CPU (0avgtext+0avgdata 1524maxresident)k
708144inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.67user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.65user 0.07system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

> /usr/bin/time md5sum file_348m
738709b181b52ddfcef3413997f91462  file_348m
0.66user 0.06system 0:00.73elapsed 99%CPU (0avgtext+0avgdata 1524maxresident)k
0inputs+0outputs (0major+80minor)pagefaults 0swaps

— Winston Smith
sumber

Saya menghargai komentar untuk downvote karena saya tidak tahu bagaimana menafsirkannya. Saya yakin uraian jawaban saya benar. Mungkin contoh perintah tidak jelas? Atau Anda tidak suka saya tidak melakukan benchmark pada perintah grep? (Saya sengaja menggunakan perintah yang lebih sederhana, md5sum, untuk mencoba mengilustrasikan poin saya.)

— Winston Smith

Saya pikir alasannya adalah, pos Anda tidak menambahkan informasi baru yang relevan dengan apa yang saya minta. Saya sudah tahu ada penundaan, dan jawaban pertama sudah memberi penjelasan mengapa itu terjadi. Tapi ya, saya mendapatkan downvotes tanpa penjelasan juga. Bahkan pada pertanyaan dengan jawaban yang bagus.

— Alex

Terima kasih @Alex untuk menyarankan alasan. Saya mencoba untuk membedakan antara waktu overhead untuk memindahkan data dari penyimpanan lokal ke memori, yang dijawab oleh jawaban pertama, dan waktu overhead untuk memindahkan data dari penyimpanan jaringan ke server lokal. Saya akan berpikir jika saya bisa menggambarkan ini lebih jelas atau memberikan contoh perintah yang lebih baik.

— Winston Smith

Saya kira setelah membaca posting Anda, saya pikir, itu masih overhead untuk memindahkan data dari mana pun disimpan, ke memori. Apakah itu dari penyimpanan jaringan, atau dari penyimpanan lokal, tidak masalah - Unix masih melihatnya bergerak dari direktori ke memori. ps-- sepertinya penjelasan saya benar-- komentar saya dengan alasan mendapat upvote.

— Alex

Begitu ya, saya menambahkan perbedaan yang tidak penting untuk apa yang Anda cari. BAIK. Ngomong-ngomong, saya menaikkan komentar Anda, jadi itu tidak memecahkan pertanyaan tentang alasan downvoting. :-)

— Winston Smith