23:59
Про время
Очередные очевидные советы по программированию.
1. Пусть программа зависла. Она вела логи и видно, в какой момент она зависла. Более старшая управляющая программа тоже вела логи. Логи надо сопоставить. Но прежде, чем делать выводы, следует сверить часы! В моём случае разница составляла две минуты (разные компьютеры, единого сервера синхронизации времени нет, интернета в локалке нет). Это была критичная разница: примерно через две минуты после зависания я выключил программу. Если бы время было одинаковым, отчёт об ошибке старшей программы сигнализировал бы о том, что зависание было старшей программой определено ещё в момент зависания. А разница в две минуты означала, что старшая программа отреагировала не на зависание, а на то, что я младшую программу прибил.
2. Пусть у нас есть система реального времени: мы посылаем куда-то запросы, при этом гарантируется, что операция выполнится, скажем, за 10 мс. В этом случае, если надо провести несколько операций, можно просто подождать 10 мс, а потом слать следующий запрос. Оказалось, что лучше этого всё равно не делать. Если есть техническая возможность, надо сначала проверить, выполнилась ли предыдущая операция. Тут есть две причины. Первая -- операция могла закончиться с ошибкой, поэтому следующую пока слать нельзя. А вторая -- хотя изготовитель и гарантировал 10 мс, по факту в редких случаях может оказаться больше. Особенно если изготовитель -- я.
1. Пусть программа зависла. Она вела логи и видно, в какой момент она зависла. Более старшая управляющая программа тоже вела логи. Логи надо сопоставить. Но прежде, чем делать выводы, следует сверить часы! В моём случае разница составляла две минуты (разные компьютеры, единого сервера синхронизации времени нет, интернета в локалке нет). Это была критичная разница: примерно через две минуты после зависания я выключил программу. Если бы время было одинаковым, отчёт об ошибке старшей программы сигнализировал бы о том, что зависание было старшей программой определено ещё в момент зависания. А разница в две минуты означала, что старшая программа отреагировала не на зависание, а на то, что я младшую программу прибил.
2. Пусть у нас есть система реального времени: мы посылаем куда-то запросы, при этом гарантируется, что операция выполнится, скажем, за 10 мс. В этом случае, если надо провести несколько операций, можно просто подождать 10 мс, а потом слать следующий запрос. Оказалось, что лучше этого всё равно не делать. Если есть техническая возможность, надо сначала проверить, выполнилась ли предыдущая операция. Тут есть две причины. Первая -- операция могла закончиться с ошибкой, поэтому следующую пока слать нельзя. А вторая -- хотя изготовитель и гарантировал 10 мс, по факту в редких случаях может оказаться больше. Особенно если изготовитель -- я.
07.06.2019 в 21:21
Для первой ситуации есть ещё одно решение — отдельный сервис, занимающийся логгированием. В Linux, например, есть syslog. У тебя останется проблема с привязкой событий к «реальному времени», но, по крайней мере, будет консистентная картина всего, что происходило в твоей распределённой системе.
-- Minoru
07.06.2019 в 23:15