Kinerja lambat saat menyalin file ke dan dari perangkat USB


11

Ketika saya menyalin file ke dan dari perangkat USB (kamera, HDD, kartu memori) sistem saya menjadi sangat lambat. Sebagai contoh jika saya ingin menutup jendela, saya menggerakkan mouse tetapi dibutuhkan sekitar 2 detik atau lebih sebelum kursor mouse bergerak. Ketika saya akhirnya mendapatkan kursor di atas x dan klik itu tidak ada yang terjadi selama 10+ detik. Saya sudah mencoba ini dengan semua efek desktop dinonaktifkan tetapi masalah tetap ada.

Perangkat Lunak: Linux Mint 9 Perangkat Keras KDE:

  • Motherboard Asus SLI
  • NVidia 6600 GPU
  • 2 GB Ram
  • 2 GB Swap
  • AMD Athlox X2 @ 3800+

Bagi saya perangkat keras ini seharusnya tidak memiliki masalah dalam menjalankan perangkat lunak ini dan tidak sampai saya menyalin file menggunakan USB. Di mana saya harus mulai mencari tahu yang ini? Saya agak berpikir driver grafis mungkin menjadi bagian dari masalah tetapi saya tidak tahu pasti.


2
periksa apakah port USB berkemampuan USB 2.0. beberapa port USB, terutama di bagian depan desktop yang digunakan hanya USB 1.0. Periksa juga apakah pengaturan BIOS Anda optimal untuk kinerja USB. Mungkin ada beberapa pengaturan kecepatan USB, dan / atau pengaturan USB lama yang dapat mempengaruhi kinerja Anda.
Tim Kennedy

Apakah perangkat diformat sebagai NTFS? Jika ya, saya akan mencoba memformatnya sebagai FAT32 (atau EXT4 jika Anda hanya berencana untuk menggunakannya di Linux).
RobinJ

3
Tampaknya ada masalah dengan halaman besar dalam manajemen memori linux . Ini jarang terjadi, tetapi sepertinya Anda telah mengamatinya.
artistoex

@artistoex - Artikel itu meringkas perilaku yang saya alami. Sayang sekali tidak ada perbaikan nyata. Adakah yang tahu jika ini diperbaiki di versi yang lebih baru? Lagipula waktu untuk upgrade.
John

seperti yang dikatakan artikel tersebut, kompilasi ulang kernel Anda dengan fitur halaman transparan yang besar dinonaktifkan.
artistoex

Jawaban:


7

Tampaknya ada masalah dengan halaman besar dalam manajemen memori linuxes . Ini jarang terjadi, tetapi sepertinya Anda telah mengamatinya.

Sebab

Ini adalah akun saya yang sangat disederhanakan tentang apa yang terjadi, menurut artikel itu.

Jika sial, suatu proses macet saat mengeluarkan akses memori. Itu karena ketika halaman besar transparan diaktifkan, akses memori dapat memicu pemadatan yang sinkron (defragmentasi memori utama,) yang artinya akses memori tidak selesai sebelum pemadatan dilakukan. Ini sendiri bukanlah hal yang buruk. Tetapi jika write-back (misalnya, data buffer ke USB) terjadi pada saat yang bersamaan, pemadatan pada gilirannya cenderung terhenti, menunggu write-back selesai.

Jadi, proses apa pun bisa berakhir menunggu perangkat lambat untuk menyelesaikan penulisan data yang disangga.

Menyembuhkan

Memutakhirkan memori utama, seperti yang dilakukan OP, mungkin membantu menunda masalah. Tetapi bagi mereka yang tidak menganggap itu pilihan, ada dua solusi yang jelas. Keduanya melibatkan kompilasi ulang kernel:

  • menonaktifkan fitur halaman besar transparan
  • menerapkan tambalan Mel seperti yang disebutkan dalam artikel

2

Ini terdengar mirip dengan pertanyaan saya di sini (di mana jawaban mengarahkan saya ke pertanyaan ini):

/programming/10105203/how-can-i-limit-the-cache-used-by-copying-so-there-is-still-memory-available-for

Tetapi teorinya sangat berbeda, dan solusi yang saya gunakan tidak terkait dengan Anda, tetapi bekerja dengan sempurna.

Saya menggunakan rsync, jadi yang harus saya lakukan adalah menggunakan opsi --drop-cache. (yang membuat salinan sedikit lebih lambat sebagai efek samping)


0

Satu-satunya trik yang saya temukan yang benar-benar berfungsi: Gnome, menyalin file nautilus ke USB berhenti pada 100% atau dekat

Jika Anda ingin mencoba beberapa trik pengguna daya, Anda dapat mengurangi ukuran buffer yang digunakan Linux dengan mengatur / proc / sys / vm / dirty_bytes menjadi sekitar 15728640 (15 MB). Ini berarti aplikasi tidak bisa mendapatkan lebih dari 15MB di atas kemajuan sebenarnya.

Efek sampingnya adalah komputer Anda mungkin memiliki throughput penulisan data yang lebih rendah dengan pengaturan ini, tetapi secara keseluruhan, saya merasa terbantu melihat bahwa suatu program berjalan lama sementara ia menulis banyak data vs. kebingungan memiliki Program tampaknya sudah selesai dengan tugasnya tetapi sistem tertinggal dengan buruk karena kernel melakukan pekerjaan yang sebenarnya. Mengatur dirty_bytes ke nilai yang cukup kecil juga dapat membantu mencegah sistem Anda menjadi tidak responsif ketika Anda kehabisan memori kosong dan menjalankan program yang tiba-tiba menulis banyak data.

Tapi, jangan terlalu kecil! Saya menggunakan 15MB sebagai perkiraan kasar bahwa kernel dapat menyiram buffer ke hard drive normal dalam 1/4 detik atau kurang. Itu membuat sistem saya tidak merasa "lamban".

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.