b****o
发帖数: 387 | 1 I have a 12 physical core, 24 virtual cores.
If I start a job with 24 process reading the same file (small file 100MB),
will this be problematic? I found the cpus are basically 0.5% for loading;
I do not know why this was triggered. |
a9
发帖数: 21638 | 2 IO永远是最慢的。
loading;
【在 b****o 的大作中提到】
: I have a 12 physical core, 24 virtual cores.
: If I start a job with 24 process reading the same file (small file 100MB),
: will this be problematic? I found the cpus are basically 0.5% for loading;
: I do not know why this was triggered.
|
n*****n
发帖数: 5277 | 3 this is not a cpu intensive problem |
Q*********r
发帖数: 69 | 4 given the small file size, you could preload the file in cache (cat file > /
dev/null) before staring the job, and the job might actually run faster ...
loading;
【在 b****o 的大作中提到】
: I have a 12 physical core, 24 virtual cores.
: If I start a job with 24 process reading the same file (small file 100MB),
: will this be problematic? I found the cpus are basically 0.5% for loading;
: I do not know why this was triggered.
|
b****o
发帖数: 387 | 5 I actually used /run/shm, and the speed, however, did not change.
If I load one process to read the 100MB, it only takes seconds; if I invoke
24 process, it takes 10 mins.
Yes, I/O is the slowest one, but 80*100MB = 8GB is not too intensive. I
am not sure if /dev/null is helpful. Is it simply
cat $file > /dev/null; myjob
? |
Q*********r
发帖数: 69 | 6 /dev/null is just for throwing away the prefetched data, cat does the
caching.
One possible reason that it runs slower with 24 processes is that all the
processes are causing out-of-order reads, which in turn would cause
unnecessary seeks, and seeks are slow ...
invoke
【在 b****o 的大作中提到】
: I actually used /run/shm, and the speed, however, did not change.
: If I load one process to read the 100MB, it only takes seconds; if I invoke
: 24 process, it takes 10 mins.
: Yes, I/O is the slowest one, but 80*100MB = 8GB is not too intensive. I
: am not sure if /dev/null is helpful. Is it simply
: cat $file > /dev/null; myjob
: ?
|
l*********s
发帖数: 5409 | 7 if it is cached, seeking should not be a concern.
【在 Q*********r 的大作中提到】
: /dev/null is just for throwing away the prefetched data, cat does the
: caching.
: One possible reason that it runs slower with 24 processes is that all the
: processes are causing out-of-order reads, which in turn would cause
: unnecessary seeks, and seeks are slow ...
:
: invoke
|
Q*********r
发帖数: 69 | 8 that is exactly why I suggested catting the file. was trying to explain what
might be happening without the prefetching ...
【在 l*********s 的大作中提到】
: if it is cached, seeking should not be a concern.
|
l*********s
发帖数: 5409 | 9 but lz already used shm, io does not seem to be the bottleneck.
what
【在 Q*********r 的大作中提到】
: that is exactly why I suggested catting the file. was trying to explain what
: might be happening without the prefetching ...
|
l*********s
发帖数: 5409 | 10 80 times? which does the number come from?
invoke
【在 b****o 的大作中提到】
: I actually used /run/shm, and the speed, however, did not change.
: If I load one process to read the 100MB, it only takes seconds; if I invoke
: 24 process, it takes 10 mins.
: Yes, I/O is the slowest one, but 80*100MB = 8GB is not too intensive. I
: am not sure if /dev/null is helpful. Is it simply
: cat $file > /dev/null; myjob
: ?
|
S*A
发帖数: 7142 | 11 try to mmap the 100M file in your 24 process and read
it using mmaped pointer. That way, there is no memcpy
from kernel to user space buffer.
10 minutes sounds too slow. What happen if you strace
one of the process? Where does it spend most of the time
on? |
