Benchmark 'Throughput.cpp' Hangs at 10MB Test
GrahamBurek opened this issue · comments
After installing cirrus via the on-site instructions on two servers, I modified throughput.cpp on both servers to point to the IP address of the server running tcpservermain. Then I ran the following commands:
On one server:
nohup ./tcpservermain & disown
On the other:
nohup ./throughput & disown
throughput.cpp began running tests, outputting the corresponding information:
throughput_128.log:
throughput 128 test
msg/s: 13.0619
bytes/s: 1671.92
throughput_406.log:
throughput 4096 test
msg/s: 13.0543
bytes/s: 53470.2
throughput_51200.log:
throughput 51200 test
msg/s: 24.9987
bytes/s: 1.27993e+06
throughput_1048576.log:
throughput 1048576 test
msg/s: 24.9772
bytes/s: 2.61905e+07
The benchmark hung after this point. nohup.out reads:
Warming up
Warm up done
size is 128
Measuring msgs/s..
Warming up
Warm up done
size is 4096
Measuring msgs/s..
Warming up
Warm up done
size is 51200
Measuring msgs/s..
Warming up
Warm up done
size is 1048576
Measuring msgs/s..
Environment:
Ubuntu 14.04 LTS (Amazon EC2 m4.large)
g++ 6.3
Also ran automake --add-missing in order to make ./bootstrap.sh work without error.
When I tried running this locally, I got the following error message at the 1 MB level:
terminate called after throwing an instance of 'cirrus::ServerMemoryErrorException'
what(): Server memory exhausted during call to put.
I'll look into this further.
I found that the server was incrementing the number of bytes used in the pool even when the item being inserted overwrote a preexisting item (it did not decrement to account for the previous item being removed.) I'm working on addressing this in #69
The 10 MB benchmark will also end up transferring 200 GB of data as it is currently configured. I'll likely also modify the throughput benchmark so that it attempts to transfer a more reasonable amount. @jcarreira
I ran with the modifications mentioned above, and have now encountered the segfault you had previously mentioned
segfault now in #76
This should be resolved in #75 now.