Sockets not working under heavy VM load?
Hi,
we have some performance issues with Glorp over P3 and, after some
investigation, I have a theory that could explain it. And I would like to
know your opinion if it is correct.
To reproduce this issue, you can try something easy. Just create a process
with normal or higher priority that will try to read something from a
socket. And, in parallel, do in a separate thread an operation that takes
all the processor time for several seconds.
[
5 seconds wait.
Time now traceCr.
ZnClient new
url: 'https://www.google.com';
get.
Time now traceCr.
] forkAt: 60.
[1000 timesRepeat: [ 10000 factorial ] ] timeToRun
(you may try a different safe server address)
The processes run in parallel until the time when the first process tries
to obtain data from the socket. Then it hangs and waits until finishing of
the second process.
My theory is that the VM socket plugin is able to receive incoming data
from the connection and save it into the buffer. In the meantime, the
reading process is waiting on the socket semaphore. But it looks like the
plugin is not able to release the semaphore while the VM is actually doing
something. It needs to wait until the VM has nothing useful to do, and then
it is finally able to release the semaphores so Pharo processes are resumed
and can start to read.
Is my theory right?
Cheers,
-- Pavel
I know this is very old, but is this still an issue today ?
On 29 Dec 2021, at 12:30, Pavel Krivanek pavel.krivanek@gmail.com wrote:
Hi,
we have some performance issues with Glorp over P3 and, after some investigation, I have a theory that could explain it. And I would like to know your opinion if it is correct.
To reproduce this issue, you can try something easy. Just create a process with normal or higher priority that will try to read something from a socket. And, in parallel, do in a separate thread an operation that takes all the processor time for several seconds.
[
5 seconds wait.
Time now traceCr.
ZnClient new
url: 'https://www.google.com';
get.
Time now traceCr.
] forkAt: 60.
[1000 timesRepeat: [ 10000 factorial ] ] timeToRun
(you may try a different safe server address)
The processes run in parallel until the time when the first process tries to obtain data from the socket. Then it hangs and waits until finishing of the second process.
My theory is that the VM socket plugin is able to receive incoming data from the connection and save it into the buffer. In the meantime, the reading process is waiting on the socket semaphore. But it looks like the plugin is not able to release the semaphore while the VM is actually doing something. It needs to wait until the VM has nothing useful to do, and then it is finally able to release the semaphores so Pharo processes are resumed and can start to read.
Is my theory right?
Cheers,
-- Pavel
Hi Sven,
it seems to be fixed, thank you for your attention.
Cheers,
-- Pavel
čt 28. 9. 2023 v 16:36 odesílatel Sven Van Caekenberghe sven@stfx.eu
napsal:
I know this is very old, but is this still an issue today ?
On 29 Dec 2021, at 12:30, Pavel Krivanek pavel.krivanek@gmail.com
wrote:
Hi,
we have some performance issues with Glorp over P3 and, after some
investigation, I have a theory that could explain it. And I would like to
know your opinion if it is correct.
To reproduce this issue, you can try something easy. Just create a
process with normal or higher priority that will try to read something from
a socket. And, in parallel, do in a separate thread an operation that takes
all the processor time for several seconds.
[
5 seconds wait.
Time now traceCr.
ZnClient new
url: 'https://www.google.com';
get.
Time now traceCr.
] forkAt: 60.
[1000 timesRepeat: [ 10000 factorial ] ] timeToRun
(you may try a different safe server address)
The processes run in parallel until the time when the first process
tries to obtain data from the socket. Then it hangs and waits until
finishing of the second process.
My theory is that the VM socket plugin is able to receive incoming data
from the connection and save it into the buffer. In the meantime, the
reading process is waiting on the socket semaphore. But it looks like the
plugin is not able to release the semaphore while the VM is actually doing
something. It needs to wait until the VM has nothing useful to do, and then
it is finally able to release the semaphores so Pharo processes are resumed
and can start to read.
Is my theory right?
Cheers,
-- Pavel