Here are some ideas:

• Increase the OS default values. This will of course affect all applications on that host.
• Increase buffer size in the P2PS (nowadays called ADS). This will of course affect all consumers that use this specific ADS. I've seen some sites that deliberately set aside a dedicated ADS for slow legacy consumers. Such ADS would then have buffer size much higher than the default.
• Enable TrafficManagement on the ADS. This is a feature of the ADS whereby it will automatically start conflating the updates if it detects that the consumer is falling behind. The way it detects this is by looking at the consumer channel's buffer utilization and when it gets above a certain threshold it will start conflating. You should of course only enable this feature is conflating is acceptable to you. I suspect that a very sudden and big burst may come too quick for this feature to kick in in, in other words: the feature cannot guarantee you that you'll never be kicked off the ADS again. Also, for conflation to have an effect there needs to something to actually conflate. If the updates are spread out on many data items (rather then within a data item) then conflation has no effect.
• Finally, and I'm sure you know this and don't want to listen to this : You are really treating the symptom, not the problem. You've got a slow consumer on your hands and on top of that you are using what can best be described as a legacy API. With the newer APIs (RFA) you would be able to alleviate the problem simply by using configuration variables even if your code logic was not as fast as one would like. Also the default mode of RFA is to read messages from the wire in a separate thread and the message is then put into a queue for the application to consume when it is ready to do so. Thus the ability to handle spikes is only limited by the memory available to the application which is a very suitable model for your scenario (don't care about latency). This is why you should try to be modern with your consumer.