Da gibts einen längeren Artikel in der Knowledgebase (#184414).
Hier ein paar Auszüge:
Error: "Warning: Cannot Record Event - Cannot Keep Up With Event Occurrence Rate!"
Problem:
The message "Warning: Cannot record event - cannot keep up with event occurrence rate!" comes out sporadically or frequently on the Domino server console. It does not appear in the Miscellaneous Events view of the log.nsf database. It will appear in the debug_outfile if this parameter is set in the notes.ini file, and it will appear in redirected console output on Unix systems.
The Event Monitor task on the Domino server is started by "load event" on the console, or with "event" on the "ServerTasks" line in the notes.ini. Once the Event Monitor is started, it processes events on the server, as configured in events4.nsf. Other server processes, when generating events, issue this warning message when the memory pool for queueing unprocessed events is full.
Solution:
The basic problem is that the Event Monitor process on this server, or the server itself, is too busy. One of the following may relieve the problem:
Fix the errors that are occurring on the server. If certain server processes discover a lot of errors at certain times, as server startup, or when daily scheduled agents run, that long list of errors will put a temporary burden on the event processing mechanisms.
Reduce the number of event notifications on the server. If there are multiple actions to take on each event, events may not be cleared quickly. Do not ask for notification on lower severity events that you are going to ignore anyway.
Do not use more expensive notification methods if they can be invoked frequently. Running a program is expensive. Relaying to another server requires a network transaction. Substitute less expensive notification methods, such as logging to a database.
Diversify the event notification load on the server. A single thread handles each type of notification action.
Reduce the number of Monitors and Probes running on the server, which may be generating more events.
Add Suppression Times to Event Messages that are flooding the server, so each occurrence doesn't cause a notification.
Improve the performance of the server through standard means - eliminate excess processes, add memory, reorganize disk configurations - all through an effective performance management program. Event Monitoring may be part of the overload.
Reduce the amount of logging done on the server. Every message written to the Miscellaneous Events view is an event, which will be written to the Event Pool, then checked in events4.nsf by the Event Monitor task to see if the Type and Severity for the message have Event Notifications requested. Even messages not triggering notifications may trigger the "Cannot record event" message.
Excessive notifications is the most important area to check. The thread for each type of notification has a built-in delay to prevent flooding the notification channel and to release the server to do other server work. Log to a database, Mail, Broadcast, Relay, and Run a program, all wait 1/10 second between notifications. Pager, NT Event Log and Unix System Log all wait 1/2 second between notifications. This means that each server will only be able to process between one and less than 10 notifications of each type per second. To check for the speed of processing notifications do one of the following:
In a database to which you are logging events, compare the time the event occurred with the time the document was created.
Change a Run program notification to something that will write a time stamp somewhere, so you can check the delay to execution.
Examples of both those steps are included below. The amount of memory the Event Manager needs to queue an individual event varies, but it must include all the information that is in an event document logged to statrep.nsf. The size of those documents ranges from 100 to 200 bytes, which is a good estimate. This memory is needed from the original occurrence until the lookup by Event Manager, and again for each notification that must be processed.
Issue the Domino console command "tell event dump" to see the amount of event memory that is allocated and in use.
Set the Event_Pool_Size parameter in notes.ini, as described below, to increase the amount of memory to queue events.
Set the Debug_Event=1 parameter in notes.ini, to look at the amount of Event Pool used just to cache the server's standard notification setup.
Also use Debug_Event=1 over problem periods to look at what is generating the event and notification activity on the server.
Standard memory leak debugging techniques are a last resort for the Event Pool, to be used only after the steps above have eliminated event system overloading. The Event Pool will grow during periods of frequent events, or during periods when notification processing backs up. The Event Pool memory blocks will not be released after that peak, but the memory within them will be reusable for queues of events and notifications. Therefore the pool may appear to be leaking, when the server is just experiencing larger and larger processing backlogs during event bursts.
Run Domino server memory dumps (load server -m), or run NSD with Memcheck. (Memcheck must be installed on Unix systems. NSD, which includes Memcheck, must be installed on Windows systems. Both are available from Lotus Support when troubleshooting suspected memory leaks.) Provide the memory statistics from "tell event dump" after Event Manager started, and after the "Cannot record event" messages, to indicate actual use of the pool memory, not just allocation of the blocks. Provide the server events4.nsf setup, and a copy of a database to which the server is logging events. The database copy must be taken at the OS level to preserve the document time stamps, but it can be an OS-level copy of a complete replica. Include the description and results of any experiments that have been run to verify that the server can keep up with the configured run program notifications.
Gruss
Jens
Thema: Hilfe - Ich komme mit einer Fehlermeldung nicht klar... (Gelesen 1558 mal)