Re: Best practice / tuning: sharedmemory on HPSM 9.32 (738 Views)
Reply
Advisor
Intensoline
Posts: 17
Registered: ‎08-06-2010
Message 1 of 9 (770 Views)
Accepted Solution

Best practice / tuning: sharedmemory on HPSM 9.32

Hi All

 

I have a question regarding tuning our system with shared memory settings: Is there any possibility / Best practice to optimize shared memory / cache?

 

At the moment we have the following settings in sm.ini:

 

shared_memory:313703342 shared_memory_address:0x80000000

 

We also have IR disabled (see sm.cfg). Please find attached the reports (reportshm, reportchache, reportsem)

 

 

OS Info: WIN 2008 R2 Std

64 bit

Installed Memory (RAM): 16 GB

CPU: 2 x Intel Xeon CPU E7 - 4870 @ 2.4 GHz

Honored Contributor
DimitarPeychev
Posts: 297
Registered: ‎11-01-2011
Message 2 of 9 (758 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

[ Edited ]

Hi,

 

 

A sample calculation for shared memory is:

48 MB + 1MB per 10 users + Shared Memory for IR

 

 However you can check all the information you need in the shared memory guide.

I am sending it attached to this message :)

HP Support
If you find that this or any post resolved your issue, please be sure
to mark it as an accepted solution.
Please also give kudo if you find it interesting :)
Advisor
Intensoline
Posts: 17
Registered: ‎08-06-2010
Message 3 of 9 (743 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi Dimitar


Thanks a lot for your reply. I will recalculate the sharedmemory value for our system according to your guide.

Considering the guide I have another question:

 

- How can I find a proper shared_memory_address? In some guides it says by running sm -reportvirtualmap:PID. If I run sm -reportvirtualmap:PID I don't get any information?! Is it true that with comment shared_memory_address parameter the system calculates itself?

- If we do not use IR, can we comment all IR Settings in sm.ini or has it another drawback?
ir_asynchronous:1
ir_boost_same_sequence:1
ir_max_shared:185703342
ir_max_relevant_answers:500
ir_autostop:1

 

Thanks a lot and regards

Flavio

Honored Contributor
DimitarPeychev
Posts: 297
Registered: ‎11-01-2011
Message 4 of 9 (738 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi again,

 

 This will be done automatically by SM. Please check the following information that I have found:

 

Automatic selection of shared memory address
The Service Manager server can now automatically select a shared memory address based on your system's available memory. This change makes allocating shared memory easier on Windows systems because you no longer have to specify one particular address for your system's shared memory. The server automatically scans your system memory and selects an address range large enough to support your system's shared memory. If for some reason your system has insufficient free memory, the server will generate an error message telling you so.

The server will automatically select a shared memory address on Windows systems as long as you do not specify an address with the shared_memory_address parameter. On all Unix-based systems, the server uses the default values of the shared_memory_address parameter based on the operating system. If you previously specified a value for the shared_memory_address parameter, you can remove it from the sm.ini file to have your system automatically select a shared memory address.

Tip: HP recommends you remove the shared_memory_address parameter on all Windows platforms so that the system automatically selects your shared memory address. This minimizes the chance that your system will fail to start due to a memory collision with a system resource assigned by Windows ASLR (Address space layout randomization).

 

HP Support
If you find that this or any post resolved your issue, please be sure
to mark it as an accepted solution.
Please also give kudo if you find it interesting :)
Honored Contributor
DimitarPeychev
Posts: 297
Registered: ‎11-01-2011
Message 5 of 9 (736 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi,

 

  About IR: How have you disable it?

I can see this:

I can see this:
#sm -que:ir -log:"D:\Program Files (x86)\HP\Service Manager 9.30\Logs\sm_ir.log"
But this  does not disable IR, only the asynchronous setting.  Are you using HS?

If yes, then IR needs to be asynchronous. So:

 

ir_asynchronous:1 and sm -que:ir

 

HP Support
If you find that this or any post resolved your issue, please be sure
to mark it as an accepted solution.
Please also give kudo if you find it interesting :)
Advisor
Intensoline
Posts: 17
Registered: ‎08-06-2010
Message 6 of 9 (727 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi Dimitar

 

Thanks again for your reply. I will comment then the shared_memory_address parameter in sm.ini as recommended by HP support. Thanks for that hint.

 

About IR:

We are running a VS, so only one VM-Machine with load balancer on it. After Upgrade to 9.32 we had some errors in the application indicating failure of IR (signal 11). An IR Regen would help but in our Testsystem the IR Regen took over 48hours to complete and we cannot afford the production to be down that long. With comment the parameter
#sm -que:ir -log:"D:\Program Files (x86)\HP\Service Manager 9.30\Logs\sm_ir.log"

the errors are gone. That's why we thought that IR is disabled... Any suggestions how to solve this problem?

 

Regards Flavio

Honored Contributor
DimitarPeychev
Posts: 297
Registered: ‎11-01-2011
Message 7 of 9 (720 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi again :)

 

So for disabaling IR you have to use ir_disable parameter :

------

Parameter
ir_disable
Description
This parameter allows you to disable the IR keys on your existing HP Service Manager system, so that the upgrade process runs faster.

Note: After the application upgrade succeeds, you can enable the IR keys again by removing the ir_disable:1 entry from the sm.ini file.

Valid if set from
Server's OS command prompt
Initialization file (sm.ini)
Requires restart of HP Service Manager server?
Yes
Possible values
1 (Disable)
Example usage
Command line: sm ir_disable:1
Initialization file: ir_disable:1

------

However I am not sure this is the best option for you. More research may be needed b ut i think you may have this issue:

http://support.openview.hp.com/selfsolve/document/KM1144719

 

Error: read_ir_cache

HP Support
If you find that this or any post resolved your issue, please be sure
to mark it as an accepted solution.
Please also give kudo if you find it interesting :)
Honored Contributor
DimitarPeychev
Posts: 297
Registered: ‎11-01-2011
Message 8 of 9 (718 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

[ Edited ]

Or this one may help you:

http://support.openview.hp.com/selfsolve/document/KM781779

 

Title:   Procedure to regen IR on test system and promote changes to production
 


There are  more than 500000 incidents in probsummary's table. The regen IR takes over 48 hours and forces not to create or edit incidents. After regen IR, sometimes the text search does not work.  Is it be possible to fully regen IR by irqueue and ir_asynchronous ?
 
 
  Solution 
 
  You cannot regen in production, as it locks the table. So there are two approaches:

1. take production down during the ir regen - which can take hours to days-, or

2. configure IR asynchronously, stop irqueue process, take a backup, then install the backup on a test machine, run the IR regen on a test system and copy scirexpert records to production. Then start irqueue process again on production.

****************

Procedure to regen IR on test system and promote changes to production:

production must be configured to run IR updates asynchronously (ir_asynchronous parameter set in sm.ini file)

1. Stop irqueue process on production

2. Take a backup of production (if taking backup should require downtime, be sure to start SM without irqueue (checkout sm.cfg file) and install it on a test environment

3. Perform IR regen on test environment, while production is up.

==> IR queries can still be run against existing (corrupt) IR index. However, all updates will be queued in irqueue file and not be updated in IR index

4. When IR regen on test is complete, you'll need to stop production system and replace contents of scirexpert table of production with the content of this table on test system

5. Start up production system including irqueue background process

==> As irqueue file will contain a lot of records now, the irqueue process will heavily work until these records are processed.

Note:

The scirexpert file keeps ir index for all dbdict that have an IR key. These IR indexes can be identified by "filename" field in scirexpert dbdict. When you IR regen only one dbdicts on test system, and irqueue process is down, the scirexpert records for other dbdicts in test and production will not be modified and be identical. So you only need to delete scirexpert records of this this filename and replace with them of the test system.

Note:
As running IR regen is a time demanding task, it would be a perfect opportunity to tune the IR index. This is described in Diagnostics and Tuning whitepaper. Especially the stop word files can be enhance IR expert performance a lot. However, as this file applies to all IR indexes, this would require ir regen of all dbdicts with ir key (I roughly say a hand full of dbdicts - but these with the most data).

******************
 

HP Support
If you find that this or any post resolved your issue, please be sure
to mark it as an accepted solution.
Please also give kudo if you find it interesting :)
Advisor
Intensoline
Posts: 17
Registered: ‎08-06-2010
Message 9 of 9 (705 Views)

Re: Best practice / tuning: sharedmemory on HPSM 9.32

Hi Dimitar

 

Thanks a lot for your help with the IR issue. As always very informative and helpful!

We will give that a try... Seems suitable to us with copy to Testsystem and do the regen there...

 

Thanks and regards

F

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.