Hi all. i’ve been wanting to send this for a while but haven’t been receiving the squeak lists, so i wasn’t sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn’t appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i’m getting the list again.
since i’m seeing some traffic on lowSpaceWatcher, i thought i’d send this along.
we are running an ancient swiki server (squeak 3.7, swiki 1.5—same as wiki.squeak.org, i guess) and we will occasionally have it go into a low space condition displaying the “space is low” debug window even though the Memory Usage Morph indicates there is a reasonable amount of memory available. in addition i don’t seem to be able to escape out of the “space is low” debug window once this happens.
i’m not asking for a fix to an old Squeak version, just wondering what might be a reasonable approach here and whether the insights might still inform current systems.
in looking at what might cause this, it seems that this is triggered when a “new:” (rather “basicNew:”) primitive fails. i understand that the VM primitive only returns success or failure, so the reason why it fails is assumed to be low memory, thus the low space condition trigger.
of course, i haven’t been able to get this to happen in production since i started looking into it, so i don’t have any debug traces to look at and trace back the real cause.
so i tried Array new: <a very large number> and was able to trigger the condition, and indeed the memory variables still show space available (Smalltalk bytesLeft is still much greater than Smalltalk lowSpaceThreshold), which would seem to indicate that the issue is not “low memory” but “impossible request” (i know this is somewhat of a distinction without a difference, since if a new: request fails it is effectively an “impossible request” but the difference i see is that the request is much larger than is usual in the system, and this occurs when memoryLeft is much greater than lowSpaceThreshold, i.e., space is NOT low)
i imagine that when this happens within a swiki/comanche request, it is caused by someone trying to overflow a buffer or something using http. when i do it from a workspace, the "space is low” debug window is triggered, but i am able to abandon it.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory” it might avoid this. but i’m not sure what error should be raised in this case. i guess some report of an “impossible” request in the web log might be useful.
i haven’t been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on some sort of fixed allocation. but the code appears to do the same thing if “basicNew:” fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don’t think anyone has ported the swiki to newer systems?)
anyway, your insights would be appreciated.
hal
Hi Hal, thanks for raising the question as it may also be of some general interest here.
On 2024-01-30 16:57, Hal Eden wrote:
Hi all. i've been wanting to send this for a while but haven't been receiving the squeak lists, so i wasn't sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn't appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i'm getting the list again.
Thanks for mentioning this. I guess it's a topic for a different discussion thread, but I also have had similar issues receiving mail from the Squeak lists, and I wonder if others are having issues but are not able to ask about it because (d'oh!) their list email is not working.
since i'm seeing some traffic on lowSpaceWatcher, i thought i'd send this along.
we are running an ancient swiki server (squeak 3.7, swiki 1.5--same as wiki.squeak.org, i guess) and we will occasionally have it go into a low space condition displaying the "space is low" debug window even though the Memory Usage Morph indicates there is a reasonable amount of memory available. in addition i don't seem to be able to escape out of the "space is low" debug window once this happens.
i'm not asking for a fix to an old Squeak version, just wondering what might be a reasonable approach here and whether the insights might still inform current systems.
Can you please say something about the operating system you are using, and what VM you are running? I have some familiarity with the unix/linux VMs of that era, as well as the low space handling from that time frame so maybe I can offer some tips.
in looking at what might cause this, it seems that this is triggered when a "new:" (rather "basicNew:") primitive fails. i understand that the VM primitive only returns success or failure, so the reason why it fails is assumed to be low memory, thus the low space condition trigger.
of course, i haven't been able to get this to happen in production since i started looking into it, so i don't have any debug traces to look at and trace back the real cause.
so i tried Array new: <a very large number> and was able to trigger the condition, and indeed the memory variables still show space available (Smalltalk bytesLeft is still much greater than Smalltalk lowSpaceThreshold), which would seem to indicate that the issue is not "low memory" but "impossible request" (i know this is somewhat of a distinction without a difference, since if a new: request fails it is effectively an "impossible request" but the difference i see is that the request is much larger than is usual in the system, and this occurs when memoryLeft is much greater than lowSpaceThreshold, i.e., space is NOT low)
i imagine that when this happens within a swiki/comanche request, it is caused by someone trying to overflow a buffer or something using http. when i do it from a workspace, the "space is low" debug window is triggered, but i am able to abandon it.
Your guess here (unreasonable buffer request originating from http request) seems quite plausible. The low space notification in a Squeak 3.7 era image might very well be triggered from an unreasonable allocation request, and you might be seeing the VM saying "help me, I cannot satisfy an allocation request". The resulting low space debug window may or may not be successfully pointing you to the original source of the problem.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory" it might avoid this. but i'm not sure what error should be raised in this case. i guess some report of an "impossible" request in the web log might be useful.
i haven't been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on so me sort of fixed allocation. but the code appears to do the same thing if "basicNew:" fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don't think anyone has ported the swiki to newer systems?)
I don't think that anyone has worked on updating Swiki to run on newer images and VMs. But aside from that, just running your existing image on newer operating systems and/or updated VMs might help. Nowadays, memory is cheap and the biggest problem that we seem to be having with the low space watcher is that it never even gets activated on platforms with seemingly infinite memory :-)
Dave
Hi Dave, all,
On 31-Jan-24 2:56:36 AM, lewis@mail.msen.com wrote:
Hi Hal, thanks for raising the question as it may also be of some general interest here.
On 2024-01-30 16:57, Hal Eden wrote:
Hi all. i've been wanting to send this for a while but haven't been receiving the squeak lists, so i wasn't sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn't appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i'm getting the list again.
Thanks for mentioning this. I guess it's a topic for a different discussion thread, but I also have had similar issues receiving mail from the Squeak lists, and I wonder if others are having issues
I can receive messages sent by members but not the commits (they're not in my junk folder in case you're wondering ;) Can't say whether they are filtered out by my email provider - Apple iCloud - any experience?). There was a brief period a few weeks ago a few commits came through to my mailbox but since then I'm not receiving commits again. Before that, another issue: all messages I sent to the group were automatically held by the admin for review but that's no longer happening... not sure why, I didn't do nothing.
but are not able to ask about it because (d'oh!) their list email is not working.
since i'm seeing some traffic on lowSpaceWatcher, i thought i'd send this along.
we are running an ancient swiki server (squeak 3.7, swiki 1.5--same as wiki.squeak.org, i guess) and we will occasionally have it go into a low space condition displaying the "space is low" debug window even though the Memory Usage Morph indicates there is a reasonable amount of memory available. in addition i don't seem to be able to escape out of the "space is low" debug window once this happens.
i'm not asking for a fix to an old Squeak version, just wondering what might be a reasonable approach here and whether the insights might still inform current systems.
Can you please say something about the operating system you are using, and what VM you are running? I have some familiarity with the unix/linux VMs of that era, as well as the low space handling from that time frame so maybe I can offer some tips.
in looking at what might cause this, it seems that this is triggered when a "new:" (rather "basicNew:") primitive fails. i understand that the VM primitive only returns success or failure, so the reason why it fails is assumed to be low memory, thus the low space condition trigger.
of course, i haven't been able to get this to happen in production since i started looking into it, so i don't have any debug traces to look at and trace back the real cause.
so i tried Array new: <a very large number> and was able to trigger the condition, and indeed the memory variables still show space available (Smalltalk bytesLeft is still much greater than Smalltalk lowSpaceThreshold), which would seem to indicate that the issue is not "low memory" but "impossible request" (i know this is somewhat of a distinction without a difference, since if a new: request fails it is effectively an "impossible request" but the difference i see is that the request is much larger than is usual in the system, and this occurs when memoryLeft is much greater than lowSpaceThreshold, i.e., space is NOT low)
i imagine that when this happens within a swiki/comanche request, it is caused by someone trying to overflow a buffer or something using http. when i do it from a workspace, the "space is low" debug window is triggered, but i am able to abandon it.
Your guess here (unreasonable buffer request originating from http request) seems quite plausible. The low space notification in a Squeak 3.7 era image might very well be triggered from an unreasonable allocation request, and you might be seeing the VM saying "help me, I cannot satisfy an allocation request". The resulting low space debug window may or may not be successfully pointing you to the original source of the problem.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory" it might avoid this. but i'm not sure what error should be raised in this case. i guess some report of an "impossible" request in the web log might be useful.
i haven't been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on so me sort of fixed allocation. but the code appears to do the same thing if "basicNew:" fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don't think anyone has ported the swiki to newer systems?)
I don't think that anyone has worked on updating Swiki to run on newer images and VMs. But aside from that, just running your existing image on newer operating systems and/or updated VMs might help. Nowadays, memory is cheap and the biggest problem that we seem to be having with the low space watcher is that it never even gets activated on platforms with seemingly infinite memory :-)
Dave
to separate this out, in case anyone is looking into mail problems. the email address i am not receiving mail from squeak-dev on: haleden@colorado.edu
hal
On Jan 30, 2024, at 6:56 PM, lewis@mail.msen.com wrote:
Hi Hal, thanks for raising the question as it may also be of some general interest here.
On 2024-01-30 16:57, Hal Eden wrote:
Hi all. i've been wanting to send this for a while but haven't been receiving the squeak lists, so i wasn't sure if it might have been discussed as part of the low-memory-watcher discussion. i was working to get my subscription to the mailing working to no avail. however, i have reviewed the archives and it doesn't appear that this aspect has been raised. btw, i finally registered with my gmail address instead, so i'm getting the list again.
Thanks for mentioning this. I guess it's a topic for a different discussion thread, but I also have had similar issues receiving mail from the Squeak lists, and I wonder if others are having issues but are not able to ask about it because (d'oh!) their list email is not working.
On Jan 30, 2024, at 6:56 PM, lewis@mail.msen.com wrote:
since i'm seeing some traffic on lowSpaceWatcher, i thought i'd send this along.
...
Can you please say something about the operating system you are using, and what VM you are running? I have some familiarity with the unix/linux VMs of that era, as well as the low space handling from that time frame so maybe I can offer some tips.
this is now running on RHEL8 under OpenStack. the executable has been migrated from a physical machine which was running whatever RH was current around 2001 to RHEL6 and now RHEL8.
in looking at what might cause this, it seems that this is triggered when a "new:" (rather "basicNew:") primitive fails.
…
Your guess here (unreasonable buffer request originating from http request) seems quite plausible. The low space notification in a Squeak 3.7 era image might very well be triggered from an unreasonable allocation request, and you might be seeing the VM saying "help me, I cannot satisfy an allocation request". The resulting low space debug window may or may not be successfully pointing you to the original source of the problem.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory" it might avoid this. but i'm not sure what error should be raised in this case. i guess some report of an "impossible" request in the web log might be useful. i haven't been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on so me sort of fixed allocation. but the code appears to do the same thing if "basicNew:" fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don't think anyone has ported the swiki to newer systems?)
i am trying adding: (Smalltalk lowSpaceThreshold < Smalltalk bytesLeft) ifTrue:[ "can't allocate, but space isn't low" self error: 'impossible request: ', sizeRequested asString ]. to basicNew:
and it seems to work--i can force an impossible request error, but as i said i haven’t had anymore actual situations happen lately.
I don't think that anyone has worked on updating Swiki to run on newer images and VMs. But aside from that, just running your existing image on newer operating systems and/or updated VMs might help. Nowadays, memory is cheap and the biggest problem that we seem to be having with the low space watcher is that it never even gets activated on platforms with seemingly infinite memory :-)
the newer OS doesn’t seem to help much—it seems like the 3.7 squeak executable that i am using still has some sort of fixed allocation. (as i mentioned when i run a more modern squeak version, i have difficulty forcing an out-of-memory condition since the OS or squeak seems to just increase the memory available, but not so with the 3.7 version.
thanks, hal
<this message is in the archive, but didn’t seem to make it into the digest>
On Jan 30, 2024, at 6:56 PM, lewis@mail.msen.com wrote:
since i'm seeing some traffic on lowSpaceWatcher, i thought i'd send this along.
...
Can you please say something about the operating system you are using, and what VM you are running? I have some familiarity with the unix/linux VMs of that era, as well as the low space handling from that time frame so maybe I can offer some tips.
this is now running on RHEL8 under OpenStack. the executable has been migrated from a physical machine which was running whatever RH was current around 2001 to RHEL6 and now RHEL8.
in looking at what might cause this, it seems that this is triggered when a "new:" (rather "basicNew:") primitive fails.
…
Your guess here (unreasonable buffer request originating from http request) seems quite plausible. The low space notification in a Squeak 3.7 era image might very well be triggered from an unreasonable allocation request, and you might be seeing the VM saying "help me, I cannot satisfy an allocation request". The resulting low space debug window may or may not be successfully pointing you to the original source of the problem.
what i wonder is whether some other error should be raised in this case rather than signalling low memory. if one were to check the state of the memory variables before signalling "out of memory" it might avoid this. but i'm not sure what error should be raised in this case. i guess some report of an "impossible" request in the web log might be useful. i haven't been able to replicate this in newer versions of squeak with a more robust memory handling system, since it seems to rely more on virtual memory than on so me sort of fixed allocation. but the code appears to do the same thing if "basicNew:" fails, so perhaps insights might be applicable here although it seems very difficult to trigger in new systems. (of course, i don't think anyone has ported the swiki to newer systems?)
i am trying adding: (Smalltalk lowSpaceThreshold < Smalltalk bytesLeft) ifTrue:[ "can't allocate, but space isn't low" self error: 'impossible request: ', sizeRequested asString ]. to basicNew:
and it seems to work--i can force an impossible request error, but as i said i haven’t had anymore actual situations happen lately.
I don't think that anyone has worked on updating Swiki to run on newer images and VMs. But aside from that, just running your existing image on newer operating systems and/or updated VMs might help. Nowadays, memory is cheap and the biggest problem that we seem to be having with the low space watcher is that it never even gets activated on platforms with seemingly infinite memory :-)
the newer OS doesn’t seem to help much—it seems like the 3.7 squeak executable that i am using still has some sort of fixed allocation. (as i mentioned when i run a more modern squeak version, i have difficulty forcing an out-of-memory condition since the OS or squeak seems to just increase the memory available, but not so with the 3.7 version.
thanks, hal
squeak-dev@lists.squeakfoundation.org
-
Hal Eden -
Jaromir Matas -
lewis＠mail.msen.com