After few hours MSDP switched to PUT=No mode

[mrmadej]

Hi,

I have a strange case with my MSDP. I have 4 MSDPs on identical servers with Linux RedHat 5. But one of them behaves very strange. After restart for few hours all is looking good. Cache is loaded, mode looks ok.

Mode : GET=Yes PUT=Yes DEREF=Yes SYSTEM=Yes STORAGED=Yes REROUTE=No COMPACTD=Yes RECOVERCRDB=No

But after few hours MSDP stops receiving data and backups are failed with status 84. 

I am getting PUT=No mode from "crcontrol --getmode" command.

Others MSDPs are ok, and all are configured the same way.

I found nothing in the logs: spoold.log and storaged.log.

Master: Linux RedHat 5.8, NBU 7.5.0.6

MSDP: Llinux RedHat 5.5, NBU 7.5.0.6

Any advice will be appreciated.

Regards

Madej

[SymTerry]

When was the last time you restarted services?

usually when you do a crcontrol and see a put=no, you will want to look at <storage_path>/log/spoold/spoold.log. Your looking for  "Storage Cache Manager: load completed"

If you see this message, and still see put=no then please contact Symantec support, (or let me know) and we can get a support ticket opened for you as their might be some sort of corruption. 

You can refer to TECH183707 for the steps described above as well.

[mrmadej]

Hi,

Thanks for response.

I have opened case with Symantec Support and waiting for contact.

It looks like there is RAM issue. In spoold.log I can see:

"Current Memory usage exceeds the Info threshold value (current value: 77, allowed value: 70)"

The Storage size is ~40TB but RAM size is only 18GB. But the space used by data is 15TB. So perhaps I need tune some parameters in  "contentrouter.cfg" file. I have to have confirmation.

I know the recommended RAM size for MSDP but in my case if I will have Storage size 18TB I would not be able to fill the whole space.

If you asking about services on MSDP server I have restarted them few times. And always waiting for "Storage Cache Manager: load complete" in spoold.log. After that, mode is switched to PUT=Yes, but just for few hours or shorter.

Regards

Madej

[mrmadej · Accepted solution]

The problem is solved.

We have to add more RAM to the MSDP server. This is the only known solution.

Regards

Madej