On our Windows Server 2012R2 64bit w/85GB memory the CPU has gotten pegged. we have Openedge 11.7.3 64bit. The _mprosrv -m1 processes end up eating about 12% until we get to 100%. Seems to happen on just 1 db(blocksize 8192 84GB in size). We adjusted the -B to 40GB thinking it would utilized more memory but it seems to have caused the CPU to peg.
I've reduced the -B to 500,000 * 8192 = 4GB and put the -B2 to 200000 = 16GB but we have nothing allocated to B2 yet.
this happened when we had the spin lock set to 25000. I just set spin lock 50,000 on all 5 databases.
We run webspeed on this server too with shared memory connections. The _progres processes for webspeed don't peg the CPU.
Webspeed Parameter file
-db F:\Progdb\OrangeDB -ld sao9 -Mm 16384 -U ws48 -P ws48
-db F:\Progdb\TablesDB -U ws48 -P ws48 -Mm 16384
-db F:\Progdb\ssdb -Mm 16384
-db F:\Progdb\icjis -Mm 16384
-db F:\progdb\DP -Mm 16384
-h 10
-yy 1930 # set offset date
-yr4def # use 4 digit year default to output a four digit year for EXPORT,MESSAGE,PUT UNFORMATTED
-inp 16384 # max no. of chars per stmt (default=4096; max=32000)
-tok 1600 # maximum number of tokens per statement (default=1024)
-T C:\Temp # Directory for temporary user files
-c 1000 # Index cursors
-s 256 # stack size (vms set to 30); default = 40;
-rereadnolock
-lkwtmo 30
-Bt 16384
-l 32768
-rand 2
the remote processes connecting are generally report programs and app servers. They use the following parameter file.
-db OrangeDB -S OrangeDB_Prod -H wsprod1.sao9.org -ld sao9 -Mm 16384
-db TablesDB -S TablesDB_Prod -H wsprod1.sao9.org -U report -P report -Mm 16384
-db ssdb -S ssdb_Prod -H wsprod1.sao9.org -Mm 16384
-db icjis -S icjis_Prod -H wsprod1.sao9.org -Mm 16384
-db DP -S DP_Prod -H wsprod1.sao9.org -Mm 16384
-Bp 16 # Private Buffers added 12/13/2019
-b # Initiate a batch session
-yy 1930 # set offset date
-h 10 # maximum number of databases
-inp 16384 # max no. of chars per stmt (default=4096; max=32000)
-tok 1600 # maximum number of tokens per statement (default=1024)
-T C:\Temp # Directory for temporary user files
-c 1000 # Index cursors
-s 256 # stack size (vms set to 30); default = 40;
-rereadnolock
-Bt 16384
-l 16384
-rand 2
Any ideas why the CPU gets pegged? Why would adjusting -B up cause the CPU to get pegged?
I've reduced the -B to 500,000 * 8192 = 4GB and put the -B2 to 200000 = 16GB but we have nothing allocated to B2 yet.
this happened when we had the spin lock set to 25000. I just set spin lock 50,000 on all 5 databases.
We run webspeed on this server too with shared memory connections. The _progres processes for webspeed don't peg the CPU.
Webspeed Parameter file
-db F:\Progdb\OrangeDB -ld sao9 -Mm 16384 -U ws48 -P ws48
-db F:\Progdb\TablesDB -U ws48 -P ws48 -Mm 16384
-db F:\Progdb\ssdb -Mm 16384
-db F:\Progdb\icjis -Mm 16384
-db F:\progdb\DP -Mm 16384
-h 10
-yy 1930 # set offset date
-yr4def # use 4 digit year default to output a four digit year for EXPORT,MESSAGE,PUT UNFORMATTED
-inp 16384 # max no. of chars per stmt (default=4096; max=32000)
-tok 1600 # maximum number of tokens per statement (default=1024)
-T C:\Temp # Directory for temporary user files
-c 1000 # Index cursors
-s 256 # stack size (vms set to 30); default = 40;
-rereadnolock
-lkwtmo 30
-Bt 16384
-l 32768
-rand 2
the remote processes connecting are generally report programs and app servers. They use the following parameter file.
-db OrangeDB -S OrangeDB_Prod -H wsprod1.sao9.org -ld sao9 -Mm 16384
-db TablesDB -S TablesDB_Prod -H wsprod1.sao9.org -U report -P report -Mm 16384
-db ssdb -S ssdb_Prod -H wsprod1.sao9.org -Mm 16384
-db icjis -S icjis_Prod -H wsprod1.sao9.org -Mm 16384
-db DP -S DP_Prod -H wsprod1.sao9.org -Mm 16384
-Bp 16 # Private Buffers added 12/13/2019
-b # Initiate a batch session
-yy 1930 # set offset date
-h 10 # maximum number of databases
-inp 16384 # max no. of chars per stmt (default=4096; max=32000)
-tok 1600 # maximum number of tokens per statement (default=1024)
-T C:\Temp # Directory for temporary user files
-c 1000 # Index cursors
-s 256 # stack size (vms set to 30); default = 40;
-rereadnolock
-Bt 16384
-l 16384
-rand 2
Any ideas why the CPU gets pegged? Why would adjusting -B up cause the CPU to get pegged?