I was running some code that was meant to hit the disk subsystem hard, and I got the following result:
GTM>F I=1:1:99999999999 S A="^A"_I I $D(@A) W "."
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>W A
^A48348
dev01>W I
48348
GTM>S I=48349 S A="^A"_I W $D(@A)
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>W A
^A48349
GTM>W $D(@A)
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>K
GTM>ZWRITE
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E1C0C
%SYSTEM-E-ENO12, Not enough space
GTM>
Very odd. Don't know if it's important. Not a critical problem for me, but I am curious to know if this is a bug as it seems to be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This behavior is not a bug. Each global variable being accessed has local process memory requirements that bind the name to the database structure it references. There is about 1KB or so per global variable. The number of global variables you can reference in any one process is dependent on your memory availability. For example, I ran your loop but since my process storage was set to "unlimited", I was able to create well over 500K global variables before my poor little 512MB RAM system started page thrashing itself to death. In short, if your object is to stress IO, do it with large globals instead of large NUMBERS of globals. The former stresses IO, the latter, stresses memory and ultimately the paging system..
Steve
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to disagree about the "not a bug" characterization. While I understand what you wrote, it seems to me that if I write valid mumps code, that is not doing something obviously wrong (like purposely filling up the database), it should not error out. The memory error seems to me to be something that should be dealt with internally. I have to admit to not calling a bug “a bug” myself at times. If it seems ok to you, we’ll call it a feature.
On the question of the validity of my test to stress the disk subsystem, I should have been a bit more specific. I was specifically trying to test how well the system performs when doing $D tests on undefined globals – which is not strictly a disk subsystem test, though it might turn out to be.
Finally, thanks much for a great open source product. Keep up the good work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was running some code that was meant to hit the disk subsystem hard, and I got the following result:
GTM>F I=1:1:99999999999 S A="^A"_I I $D(@A) W "."
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>W A
^A48348
dev01>W I
48348
GTM>S I=48349 S A="^A"_I W $D(@A)
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>W A
^A48349
GTM>W $D(@A)
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E2348,%SYSTEM-E-ENO12, Not enough space
At M source location +1^GTM$DMOD
GTM>K
GTM>ZWRITE
%GTM-E-MEMORY, Central memory exhausted during request for 34836 bytes from 0xD28E1C0C
%SYSTEM-E-ENO12, Not enough space
GTM>
Very odd. Don't know if it's important. Not a critical problem for me, but I am curious to know if this is a bug as it seems to be.
This behavior is not a bug. Each global variable being accessed has local process memory requirements that bind the name to the database structure it references. There is about 1KB or so per global variable. The number of global variables you can reference in any one process is dependent on your memory availability. For example, I ran your loop but since my process storage was set to "unlimited", I was able to create well over 500K global variables before my poor little 512MB RAM system started page thrashing itself to death. In short, if your object is to stress IO, do it with large globals instead of large NUMBERS of globals. The former stresses IO, the latter, stresses memory and ultimately the paging system..
Steve
I have to disagree about the "not a bug" characterization. While I understand what you wrote, it seems to me that if I write valid mumps code, that is not doing something obviously wrong (like purposely filling up the database), it should not error out. The memory error seems to me to be something that should be dealt with internally. I have to admit to not calling a bug “a bug” myself at times. If it seems ok to you, we’ll call it a feature.
On the question of the validity of my test to stress the disk subsystem, I should have been a bit more specific. I was specifically trying to test how well the system performs when doing $D tests on undefined globals – which is not strictly a disk subsystem test, though it might turn out to be.
Finally, thanks much for a great open source product. Keep up the good work.