You are not logged in.
Pages: 1
Hello,
I noticed a huge gap between IO operations on my work mac and my archlinux laptop. Even if the latter has much better hardware, running some IO intensive operations will take twice the amount of time than the mac (20 minutes vs 10 minutes).
Using iotop I notice that the 4 threads of my process are using near 1M/s each most of the time
Analyzing the IO operations, I noticed that after some minutes of running, the same IO subroutine that was taking 20-30ms starts taking 300 and eventually 600ms.
I guess that there is something limiting the quota of IO of the process, so I tried:
- to reduce swappiness https://wiki.archlinux.org/index.php/Swap#Swappiness setting it to 10, but I didn't notice any improvements (my arch has 32gb ram and no swap file/partition).
- cgroups, since maybe the process was running out of its quota. So I tried to move my process to root cgroup for IO (that should be /sys/fs/cgroup/blkio/tasks) but I saw no difference
- put all pids of the my process to ionice 0 at best effort class
nothing seems to affect it.
I wanted to ask here if there are other way I can find the bottleneck or other causes
Offline
i2c? RS-232? SMBus? SATA? 802.11? USB3?
What chipsets? What drivers?
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
I finished doing some research and tests, and I found my own answer.
Noticing that the jdb2 (journaling) process was taking too much IO, I created and used a fastIO fs disabling a bunch of checks. From my fstab
data=writeback,noatime,rw,nosuid,nodev,noblock_validity,delalloc,nojournal_checksum,discard,nobarrier,nouser_xattr,noacl
I went down to ~4 minutes. Learned the trick, I used a directory under /tmp, so using tmpfs I was mapping directly everything to RAM. I went down to 3:30 minutes.
I hope it could be useful to someone else!
Offline
Welcome to Arch Linux. So, we were talking about disk access
Consider that you did not really provide any information in your first post as to the type of I/O
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Sorry, since I was looking at something machine-independent I didn't think about hardware or anything low level. It turned out I was wrong and the IO device was all I needed
Offline
You should consider that changing too much from the default takes you to less tested code paths. These less tested code paths might contain bugs, or new bugs might slip through testing when a new kernel is released.
R00KIE
Tm90aGluZyB0byBzZWUgaGVyZSwgbW92ZSBhbG9uZy4K
Offline
Pages: 1