Is there a reason you want to use poll instead of Solaris event ports? There is a restricted option just in case there are problems with event ports that weren't discovered during QA stress testing, but maintaining and testing two code paths indefinitely is expensive so use of the restricted option won't be supported unless such a problem is reported through Messaging Server support channels.
Yes there is a reason. Stress test i did shows that using new port event approach consumes more CPU resources then old pool() method.
I'm not talking about performance just CPU usage. So, I suppose port event method can be hardly applied for poor hardware customer uses
SF v240 6Gb RAM as back-end mail server. It was perfectly enough for usage under previous release of communication suite 7u2 but definitely not quite powerful for the newest release 7u4.
The option name is "base.preferpoll" (in unified config) or "local.preferpoll" (legacy config). If you want to use those options with non-default settings in production, please contact support. With the poll approach, there is a nanosleep() call in the main loop to work around the scalability problems with the poll system call. This causes the system to appear to use less CPU but it does so at the expense of higher latency. With the event port approach, there's no artificial nanosleep call so events are dispatched immediately and the system can spin faster through the main loop under moderate load.
Unfortunately this option impact to imapd process only. The stored process use event port approach anyway.
1 person found this helpful
You want the fix for bug 16311689: reduce CPU usage for stored. The workaround for that bug is: configutil -o local.store.deadlock.checkinterval -v 100.