Hi,
Anybody got any experience or comments on running a script like this while a GTm application is running.
pkill -STOP mumps
sync
pkill -CONT mumps
This is a single user application ( cash register ) so there are no issues re database availability etc while this is run.
This is run at the end of each sale to ensure data is written to disk ( HDD write cache is disabled )
There may be mumps processes running that are downloading files and updating globals.
Initial tests have not thrown up any problems but I'm concerned that it may cause GTm issues.
TIA,
Chris Dunworth
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For starters, it would be remiss of me if I didn't make a plug for purchasing support. While the GT.M software is free to use, a support agreement is appropriate for a production deployment such as yours. You can write to me off-list at ks dot bhaskar at fisglobal dot com if you want to discuss it.
pkill -STOP mumps should terminate all mumps processes, and therefore is likely not what you want. Also, the pklll -CONT mumps would therefore not have any mumps process to continue.
Are you journaling your databases? Look at the VIEW JNLFLUSH / JNLWAIT commands that you can put inside your program. If you are not running journaling (which I consider mandatory for any database that you are not prepared to throw away after a crash), look at VIEW DBFLUSH / DBSYNC. If you want to do it from outside the application, consider a MUPIP FREEZE ON followed by OFF, which flushes the database as part of the freeze.
For current GT.M documentation, go to http://fis-gtm.com and click on the User Documentation tab.
Regards
-- Bhaskar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am told pkill STOP will suspend the process, not terminate it. As each process has the database engine within it, we strongly recommend against suspending GT.M processes. Also, suspending mumps processes does not flush buffers to disk.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Bhaskar,
Thanks for prompt reply. I will discuss purchasing support with the customer. The flushing of buffers to disk is not just confined to GTm processes. There are other processes running that handle payments, giftcards etc.
The objective in suspending mumps processes is to avoid these processes doing any updates while the operating system dirty buffers are flushed to disk.
I'm learning quite a bit about flushing writes to disk on Linux. A bit of a black art but a lot of options if you know where to look. Some new registers with 4GB RAM instead of older ones with 256MB ( yes that's MB ) highlighted theses issues because Linux by default uses a big chunk of unused memory ( 20%) as write buffers. We ended up with more memory and slower system !!!
Regards,
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
Anybody got any experience or comments on running a script like this while a GTm application is running.
pkill -STOP mumps
sync
pkill -CONT mumps
This is a single user application ( cash register ) so there are no issues re database availability etc while this is run.
This is run at the end of each sale to ensure data is written to disk ( HDD write cache is disabled )
There may be mumps processes running that are downloading files and updating globals.
Initial tests have not thrown up any problems but I'm concerned that it may cause GTm issues.
TIA,
Chris Dunworth
Chris --
For starters, it would be remiss of me if I didn't make a plug for purchasing support. While the GT.M software is free to use, a support agreement is appropriate for a production deployment such as yours. You can write to me off-list at ks dot bhaskar at fisglobal dot com if you want to discuss it.
pkill -STOP mumps should terminate all mumps processes, and therefore is likely not what you want. Also, the pklll -CONT mumps would therefore not have any mumps process to continue.
Are you journaling your databases? Look at the VIEW JNLFLUSH / JNLWAIT commands that you can put inside your program. If you are not running journaling (which I consider mandatory for any database that you are not prepared to throw away after a crash), look at VIEW DBFLUSH / DBSYNC. If you want to do it from outside the application, consider a MUPIP FREEZE ON followed by OFF, which flushes the database as part of the freeze.
For current GT.M documentation, go to http://fis-gtm.com and click on the User Documentation tab.
Regards
-- Bhaskar
I am told pkill STOP will suspend the process, not terminate it. As each process has the database engine within it, we strongly recommend against suspending GT.M processes. Also, suspending mumps processes does not flush buffers to disk.
Hi Bhaskar,
Thanks for prompt reply. I will discuss purchasing support with the customer. The flushing of buffers to disk is not just confined to GTm processes. There are other processes running that handle payments, giftcards etc.
The objective in suspending mumps processes is to avoid these processes doing any updates while the operating system dirty buffers are flushed to disk.
I'm learning quite a bit about flushing writes to disk on Linux. A bit of a black art but a lot of options if you know where to look. Some new registers with 4GB RAM instead of older ones with 256MB ( yes that's MB ) highlighted theses issues because Linux by default uses a big chunk of unused memory ( 20%) as write buffers. We ended up with more memory and slower system !!!
Regards,
Chris