Я пробовал грузить сейфмод с последующим отключением всего что не нужно. Кол-во ошибочных выполнений упало до 2х-3х на INT_MAX выборке. Пока не знаю как занизить частоту на маке — попробую разобраться вечером.
Спасибо за наводку. Тут пишут что «macOS before 10.13.5 is affected» (не знаю насколько это серьезный источник). Вчера обновился до System Version: macOS 10.13.5 (17F77) но проблема, к сожалению, не исчезла.
Глючат, но на удивление очень редко. Иногда bazel падает с тем же аут-оф-баунд при запуске. Иногда комп полностью зависает при сворачивании окна в док (в тот момент когда оно анимировано «уплывает»). Больше никаких проблем не замечал.
Еще интересно — по совету из комментов выше пробовал запускать тест внутри докер контейнера на убунту и ошибка не повторяется (хотя инструкции там те же).
— Обновить ОС не помогло.
— Я попробовал запустить докер контейнер с убунту и собрать бинарник там. Внутри контейнера ошибка не повторилась! (проверил gdb что sse инструкции используются). Проверить на реальном live cd пока нет возможности так как на ноутбуке только usb-c порты :( Проверю на «чистом» линуксе как появится возможность.
Версия HotSpot java version «1.8.0_171».
У коллег проблема не повторялась. Исходя из того что проблема появлялась очень редко и воспроизвелась на простом cpp методе, я думаю что дело именно в железе конкретного компьютера.
Добавление strictfp к бенчмарк классу в Java ошибку не убрало. Не уверен как это можно включить для clang. В интернете я нашел что можно проверить std::numeric_limits::is_iec559 — «возвращает» 1.
Было бы хорошо, если бы помимо «Reindexer — полностью in-memory база данных» вы бы указали что Reindexer в тестах был в embedded режиме и что флаш данных на диск происходит асинхронно.
Это важные особенности — так как отсутствие слоя сети существенно увеличивает рпс быстрых однотипных операций (оптимизации компилятором всего бенчмарка, меньше вытеснений кешлайнов и тп), а асинхронная запись на диск не только ничего не блокирует, но еще и может приводить к потере данных. С этими уточнениями будет понятно откуда такой выигрыш в производительности и не будет нужды смотреть в код.
В статье написано «Аллокация выглядит как уменьшение указателя, указывающего на начало свободной памяти.», а затем идет пример с аллокацией 16 байт в диапазоне 0х4000:0х4010. Не должен ли быть диапазон 0х3990:0х4000, если следовать 1му утверждению?
Платформа JEE. Само понятие высоконагруженной системы говорит о том, что стандартные решения не подходят или нуждаются в доработке. Тк готовые решения обычно подходят для всего и ничего не знают про ваш домен, то они вряд ли смогут применить оптимизации, доступные только вам. При разработке подобных систем стоит выбирать несвязанные (опенсорсные) компоненты и включать их в проект. Например, отлично подходит embedded jetty в качестве сервера (его отдельные куски потом можно будет переписать). В качестве IOC контейнера лучше выбрать guice, который решает только одну задачу, чем спринг, который решает сразу все.
Очереди. Время обработки сообщения, попавшего в конец очереди размера x10, будет во много раз меньше чем время ожидания его обработки. Нет смысла заставлять пользователя ждать когда мы при этом ничего не делаем. Очереди должны быть размером x1-x2 и необходимо постоянно мониторить их размер. По хорошему очереди всегда должны быть пустыми. Исключение составляют очереди, которые обрабатываются батчем (например, из-за io).
Логирование. Не нужно стесняться логировать. Чем больше информации в логах, тем потом проще расследовать баги. До тех пор пока мы пишем на диск в отдельном потоке, iostat не показывает критичных спайков, и сброс на диск не забивает очередь логгера, нужно писать все что есть в лог.
Мониторинг. + мониторинг gc, safepoint'ов и прочего в самой java.
И еще немного от себя:
Профилирование. Нужно освоить JMC и периодически просматривать дампы на предмет больших и не нужных аллокаций/промоушенов. Так же в поиске горлышке очень поможет расстановка меток в коде и их последующей визуализации (как это сделано в js профилировщике, например, в ff).
CI нагрузочное тестирование. Если проводить тесты по коммитно, то сразу будет видна деградация производительности.
Тоже вспомнился провал редизайна имхонета в 2013. Вместо полнофункционального сайта с рекомендациями подсунули поделку для планшетов. Тогда гневно ушел на goodreads дожидаться, что все вернут обратно, но с того момента там ничего и не изменилось. Публичной статистики у имхонета нет (или я не нашел), но если сравнить кол-во отзывов на Аватар (2009) и Интерстеллар (2014) то получается 3260 и 683 отзывов соответственно. Не то, чтобы это объективная метрика, но косвенно подтверждает что дела у них не стали лучше. Если ребята пойдут тем же путем, то боюсь что мы наблюдаем закат кинопоиска.
«Невежливые ответы часто исходят из Зоны. Возможно, вас раздражает, что вас вытаскивают из Зоны или кто-то мешает вашим попыткам войти в Зону. Как бы то ни было, грубость часто объясняется вашей связью с Зоной.» вот эту цитату из книги по достоинству оценили бы братья Стругацкие.
Без высшего образования вы не сможете получить BC при переезде и работодателю придется доказывать в местном управлении что он не смог найти резидента на ваше место. Еще вы не сможете менять работу (т.е. пермит будет привязан к работодателю). И вам придется ждать 5 лет вместо 2х для получения ВНЖ.
Так выглядят формальные правила. В реальности «доказывать в местном управлении что он не смог найти резидента на ваше место» для ИТ специальностей это просто запрос от работодателя. И вам с большой вероятностью переделают пермит если вы принесете новый контракт на месте (сам я так не делал, но коллеги утверждают что можно). Главное все рассказать что у вас нет вышки (на интервью, в посольстве и т.д.) т.к. в моем случае мне в России сделали визу на дальнейшее получение БЦ и по приезду возникли не большие сложности.
Вообще там есть опции типа «зарплата больше 67.5к в год или 5 лет опыта» == «диплом» но они вроде как не приняты. Работодатели на счет диплома не особо беспокоятся и переживать из-за этого не стоит.
Отличная статья!
Действительно странно. ОС вчера обновил до актуальной.
Еще интересно — по совету из комментов выше пробовал запускать тест внутри докер контейнера на убунту и ошибка не повторяется (хотя инструкции там те же).
yadi.sk/i/nVpyIvDJ3Y8qzs
Сравнение дабла: yadi.sk/i/1z-WK0H03Y8ota
Сравнение флоата: yadi.sk/i/bnn8n6tm3Y8oyk
— Обновить ОС не помогло.
— Я попробовал запустить докер контейнер с убунту и собрать бинарник там. Внутри контейнера ошибка не повторилась! (проверил gdb что sse инструкции используются). Проверить на реальном live cd пока нет возможности так как на ноутбуке только usb-c порты :( Проверю на «чистом» линуксе как появится возможность.
У коллег проблема не повторялась. Исходя из того что проблема появлялась очень редко и воспроизвелась на простом cpp методе, я думаю что дело именно в железе конкретного компьютера.
Добавление strictfp к бенчмарк классу в Java ошибку не убрало. Не уверен как это можно включить для clang. В интернете я нашел что можно проверить std::numeric_limits::is_iec559 — «возвращает» 1.
Это важные особенности — так как отсутствие слоя сети существенно увеличивает рпс быстрых однотипных операций (оптимизации компилятором всего бенчмарка, меньше вытеснений кешлайнов и тп), а асинхронная запись на диск не только ничего не блокирует, но еще и может приводить к потере данных. С этими уточнениями будет понятно откуда такой выигрыш в производительности и не будет нужды смотреть в код.
Платформа JEE. Само понятие высоконагруженной системы говорит о том, что стандартные решения не подходят или нуждаются в доработке. Тк готовые решения обычно подходят для всего и ничего не знают про ваш домен, то они вряд ли смогут применить оптимизации, доступные только вам. При разработке подобных систем стоит выбирать несвязанные (опенсорсные) компоненты и включать их в проект. Например, отлично подходит embedded jetty в качестве сервера (его отдельные куски потом можно будет переписать). В качестве IOC контейнера лучше выбрать guice, который решает только одну задачу, чем спринг, который решает сразу все.
Очереди. Время обработки сообщения, попавшего в конец очереди размера x10, будет во много раз меньше чем время ожидания его обработки. Нет смысла заставлять пользователя ждать когда мы при этом ничего не делаем. Очереди должны быть размером x1-x2 и необходимо постоянно мониторить их размер. По хорошему очереди всегда должны быть пустыми. Исключение составляют очереди, которые обрабатываются батчем (например, из-за io).
Логирование. Не нужно стесняться логировать. Чем больше информации в логах, тем потом проще расследовать баги. До тех пор пока мы пишем на диск в отдельном потоке, iostat не показывает критичных спайков, и сброс на диск не забивает очередь логгера, нужно писать все что есть в лог.
Мониторинг. + мониторинг gc, safepoint'ов и прочего в самой java.
И еще немного от себя:
Профилирование. Нужно освоить JMC и периодически просматривать дампы на предмет больших и не нужных аллокаций/промоушенов. Так же в поиске горлышке очень поможет расстановка меток в коде и их последующей визуализации (как это сделано в js профилировщике, например, в ff).
CI нагрузочное тестирование. Если проводить тесты по коммитно, то сразу будет видна деградация производительности.
Так выглядят формальные правила. В реальности «доказывать в местном управлении что он не смог найти резидента на ваше место» для ИТ специальностей это просто запрос от работодателя. И вам с большой вероятностью переделают пермит если вы принесете новый контракт на месте (сам я так не делал, но коллеги утверждают что можно). Главное все рассказать что у вас нет вышки (на интервью, в посольстве и т.д.) т.к. в моем случае мне в России сделали визу на дальнейшее получение БЦ и по приезду возникли не большие сложности.
Вообще там есть опции типа «зарплата больше 67.5к в год или 5 лет опыта» == «диплом» но они вроде как не приняты. Работодатели на счет диплома не особо беспокоятся и переживать из-за этого не стоит.
Ну вот зачем это пререводить?