Моих ожиданий приложений в epoll_wait
гораздо дольше, чем я, указанных в тайме-ауте:epoll_wait блоков для дольше таймаут
22578 09:33:46.959791 epoll_wait(5, <unfinished ...>
22578 09:33:50.010794 <... epoll_wait resumed> [], 128, 1498) = 0
...
22034 09:35:07.686896 epoll_wait(5, <unfinished ...>
22034 09:35:09.482526 <... epoll_wait resumed> [{EPOLLIN, {u32=151458248, u64=151458248}}], 128, 362) = 1
...
22036 09:35:41.433241 epoll_wait(5, <unfinished ...>
22036 09:35:43.176881 <... epoll_wait resumed> [], 128, 97) = 0
Я попросил тайм-аут для одного значения, но время показывает, что он ждет гораздо более длительного интервала.
Время от логарифмической проверки - я получил его от strace
. Что делать, чтобы сделать тайм-аут в epoll
более мелкозернистым? И почему epoll_wait
ТАК МНОГО НЕКОТОРЫХ?
Я пропустил много промежуточной обработки в других потоках в моем обработать. Из этой обработки в других потоках я делаю вывод, что я не в состоянии ресурсного голода. Можете ли вы дать более конкретные идеи, как исследовать дальше? Единственная идея, которую я имею, - исследовать операции планировщика. Начните с записи перфоманса и ...? – user1641854
Попробуйте запустить таймер 1 мс (с 'epoll_wait' или timerfd) в отдельном потоке и проверить его дрожание. –
Я смог стабильно воспроизвести проблему, и действительно, основной причиной является планировщик. – user1641854