较小超时值的 epoll 性能
我有一个单线程服务器进程，它通过 epoll 在循环中监视很少（大约 100 个）套接字，我的问题是如何确定 epoll_wait 超时值的最佳值，因为这是一个单线程进程，所有内容都是由 epoll_wait 触发的，如果套接字上没有活动，程序保持空闲状态，我的猜测是，如果我给出的超时太小，这会导致太多的 epoll_wait 调用，那么也没有什么害处，因为即使我的进程做了太多的事情epoll_wait 调用，否则它会处于空闲状态，但还有一点，我在这个（8 核）盒子上运行许多其他进程，比如 100 个其他进程，它们是该进程的客户端，我想知道超时值如何影响 cpu 上下文切换，即如果我给出的超时值太小，导致许多 epoll_wait 调用，那么我的服务器进程是否会等待更多次，而当我给出较大的超时值时，这会导致更少的 epoll_wait 调用。
任何想法/想法。
谢谢
I have a single thread server process that watches few (around 100) sockets via epoll in a loop, my question is that how to decide the optimum value of epoll_wait timeout value, since this is a single threaded process, everything is triggered off epoll_wait , if there is no activity on sockets, program remains idle, my guess is that if i give too small timeout, which causes too many epoll_wait calls there is no harm because even though my process is doing too many epoll_wait calls, it would be sitting idle otherwise, but there is another point, I run many other processes on this (8 core) box, something like 100 other process which are clients to this process, I am wondering how timeout value impacts cpu context switiching, i.e if i give too small timeout which results in many epoll_wait call will my server process be put in waiting many more times vs when I give a larger timeout value which results in fewer epoll_wait calls.
any thoughts/ideas.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我相信如果你的进程没有任何事情要做，就没有充分的理由让它醒来。只需将超时设置为您第一次需要做某事的时间即可。例如，如果您的服务器具有在 N 秒不活动后断开客户端连接的语义，请将 epoll 超时设置为假设没有活动则必须断开第一个客户端连接之后的时间。换句话说，将其设置为：
min{expire_time(client);对于每个客户端} - current_time
或者，如果结果为负，您可以立即断开至少一个客户端的连接。一般来说，这不仅适用于断开客户端连接；您可以将上述内容抽象为应用程序中的“软件计时器”。
我没有看到你提到的这种妥协。如果您使用的超时时间比必须的要小，那么您将在必须之前醒来，然后，大概会重新入睡，因为您无事可做。这样做有什么好处呢？另一方面，您不得使用超过您必须的超时值 - 因为这会使您的程序不遵守断开连接超时策略。
如果您的程序不等待任何基于时间的事件（例如断开客户端连接），只需将 epoll_wait() 超时值设置为 -1，使其永远等待。
更新 如果您担心当其他进程处于活动状态时此进程会获得较少的 CPU，只需给它较低的好值（调度程序优先级）即可。另一方面，如果您担心服务器进程在空闲时会被交换到磁盘以支持其他进程，则可以 避免将其换出。 （或者你可以降低/proc/sys/vm/swappiness，影响所有进程）
I believe there is no good reason to make your process wake up if it has nothing to do. Simply set the timeout to when you first need to do something. For example, if your server has a semantic of disconnecting a client after N seconds of inactivity, set the epoll timeout to the time after the first client would have to be disconnected assuming no activity. In other words, set it to:
min{expire_time(client); for each client} - current_time
Or, if that's negative, you can disconnect at least one client immediately. In general, this works not only for disconnecting clients; you can abstract the above into "software timers" within your application.
I'm failing to see this compromise you've mentioned. If you use a timeout any smaller than you have to, you'll wake up before you have to, then, presumably, go back to sleep because you have nothing to do. What good does that do? On the other hand, you must not use a timeout any larger than what you have to - because that would make your program not respect the disconnect timeout policy.
If your program is not waiting for any time-based event (like disconnecting clients), just give epoll_wait() timeout value -1, making it wait forever.
UPDATE If you're worried that this process being given less CPU when other processes are active, just give it lower nice value (scheduler priority). On the other hand, if you're worried that your server process will be swapped out to disk in favour of other processes when it's idle, it is possible to avoid swapping it out. (or you can just lower /proc/sys/vm/swappiness, affecting all processes)