Blog updated
Did a maintenance of my blog this evening and updated from Pebble version 2.3.2 to 2.6.2 so lots of new stuff to look through. It looks like the update went fine but if you experience something "weird" please let me know. Thanks.
Disabling HTTPS communication between IHS WAS Plugin and WAS servers
Many people believe that you have to have multiple servers to run IBM Connections - this simply isn't true! There's no reason why you cannot run everything of the same server which is what we do here at the office. When you do that, if all servers are inside the firewall - or if you simply doesn't care about the security that it provides - you can disable the IHS WAS Plugin from communicating with the WAS server using SSL. A benefit from this is among other things that you do not have to care about certificates between the IHS WAS Plugin and the WAS server which simplifies installation and management.
Any way... For a while I've doing this configuration change manually directly in plugin-cfg.xml (by commenting the HTTPS transport out) until it bit us the other day. So I finally decided to find a proper, correct, solution. And of course there is a way to do this and it's very well documented in IBM Technote 1452735. So if you want to make that change go ahead and do it - I did and it's working flawlessly.
Windows 2008 64-bit can cause a significant CPU increase and I/O degradation when Domino opens many databases
Had a customer report the above issue and have it fixed by IBM so I thought others might benefit from it. The issue has been fixed as IBM SPR# KBRN8AKKA9. The technote is 1449825 and contains a lot of good info. Setting notes.ini "Disable_Random_RW_File_ATTR=1" fixes the issue.
"After Domino opens many NSF files in quick succession during a backup, the Virtual Address Space of the OS system cache may be completely used up (for example, 1TB of data may be used in this OS cache). Successive calls into the OS cache manager to get memory from the OS system cache then results in mapping/unmapping of views from the system cache. These mapping/unmapping operations takes a lot of CPU time and as a result shows as high OS CPU usage. In addition, because the large OS system cache may now reside on the disk (the RAM is not large enough to hold the OS system cache) this results in significant I/O on the system."