New answers tagged io
none really is a poorly-documented alias for noop. See here for more details.
I think what happens is that the initial performance of 30-40 MB/s is because of linux kernel's caching (and any other caching that may be going on on a hardware level). Once that caching has been "used up" actual disk access starts to kick in and performance drops. In addition in order for dd to have better performance set the bs= argument to a reasonably ...
The best way to attack it is to look at http://www.brendangregg.com/linuxperf.html and follow Brendan's advice. Specifically you want his iosnoop tool that will tell you who access the storage the most. But you'll do yourself a big favor if you read through it to learn his thought process and methodologies as that would benefit you a lot in the long term.
You can use atop. It's the top-alike tool that will show you all kind of stuff about your running processes. It will also highlight the resources that are hogged (being used heavily or becoming bottleneck for the processes). It can also record the state of the system every X minutes, and that feature can be used as "poor man performance monitor". To see ...
You can use iotop command. It's top-like I/O monitor
The process is writing data to a remote disk mounted on /home There's probably your answer. Process state D is not DOWN, it is uninterruptible sleep and typically means some I/O to finish. As you have a network share, depending on conditions it might not show as I/O wait to you, and might not consume much CPU as your system is waiting. However, for you ...
If the CPU is not busy, then your process is presumably waiting for something external. I'd imagine there's a good chance you'd make sense of it by looking at what system calls are taking longest with strace. Falling that, try using a profiler to find out what the code is doing. Does your code use mmap'd IO? I'm thinking that might not get reported as ...
Which version of MySQL server do you use? After 5.5 you can use the performance_schema to get realtime statistics from the database. I'd start querying the table_io_waits_summary_by_table table_io_waits_summary_by_table table_lock_waits_summary_by_table to see what is happening exactly. An another solution would be if you check the buffer pool ...
Let us read the manual page for the underlying library call: Programs can use posix_fadvise() to announce an intention to access file data in a specific pattern in the future, thus allowing the kernel to perform appropriate optimizations. The advice applies to a (not necessarily existent) region starting at offset and extending for len bytes (or ...
Alternate solution is having separate disks and cycle between them. So when your done logging to one disk, you swap to the other, and then you could use lots of IO to remove stuff, and not burden the active disk.
Top 50 recent answers are included