ŹR
Нахер оке запускаешь когда в одном инстансе не приходится париться ни с чем
Size: a a a
2020 June 03
LL
холивара ради - я не знаю конечно, может, кто-то сможет объяснить, зачем в бою держать несколько коннектов к разным базам и всем этим пользоваться одновременно? есть хоть один кейс у кого?
Могу представить кейс, когда нужно уметь очень быстро добавлять новые инстансы приложения в прод
Тогда не будет времени на настройку подключений и самым очевидным решением будет просто создавать точные копии приложений
Тогда не будет времени на настройку подключений и самым очевидным решением будет просто создавать точные копии приложений
AL
Нахер оке запускаешь когда в одном инстансе не приходится париться ни с чем
зависит от масштаба имхо. но по идее там, где можно обойтись одним приложением, и нагрузка обычно такая, что отдельные реплики на чтение для чтения делать хз стоит ли
AL
Могу представить кейс, когда нужно уметь очень быстро добавлять новые инстансы приложения в прод
Тогда не будет времени на настройку подключений и самым очевидным решением будет просто создавать точные копии приложений
Тогда не будет времени на настройку подключений и самым очевидным решением будет просто создавать точные копии приложений
объединить в развёртывании несколько инстансов? можно ж даже на одну тачку несколько инстансов забацать если сильно хочется
LL
Нахер оке запускаешь когда в одном инстансе не приходится париться ни с чем
На хероке* ?
LL
объединить в развёртывании несколько инстансов? можно ж даже на одну тачку несколько инстансов забацать если сильно хочется
Да, развернуть сразу несколько
И при этом, разварачивает машинка
И при этом, разварачивает машинка
LL
Ну кароче я реально не могу придумать когда без этой либы не обойтись, но могу придумать когда на скорую руку эту либу можно использовать
AL
на скорую - да, безусловно. но по уму всё это без такого решается (ваш кэп)
LL
DR
Я пару дней назад спрашивал про uuid1. У нас в одной системе был интересный боттлнек, при нагрузке, стандартные от друга(якобы) не зависящие операции тормозили и не получалось загрузить более 25 из 64 ядер.
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
LL
Dmitry Russ (Aleksandrov)
Я пару дней назад спрашивал про uuid1. У нас в одной системе был интересный боттлнек, при нагрузке, стандартные от друга(якобы) не зависящие операции тормозили и не получалось загрузить более 25 из 64 ядер.
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
Вот это расследование. Можно даже статью написать
МБ
как сконвертить юникод в 1251?
V
Dmitry Russ (Aleksandrov)
Я пару дней назад спрашивал про uuid1. У нас в одной системе был интересный боттлнек, при нагрузке, стандартные от друга(якобы) не зависящие операции тормозили и не получалось загрузить более 25 из 64 ядер.
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
uuid1 не даёт коллизий даже теоретически в отличии от
V
Dmitry Russ (Aleksandrov)
Я пару дней назад спрашивал про uuid1. У нас в одной системе был интересный боттлнек, при нагрузке, стандартные от друга(якобы) не зависящие операции тормозили и не получалось загрузить более 25 из 64 ядер.
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
В конечном итоге, выяснилось, что проблема была в uuid1. Каждая генерация uuid1 вызывает: :inet.getifaddrs(), которая делает запрос к одному процессу и та вообще уходит в порт, чтобы считать mac address.
Так вот, выяснилось, что именно из-за этой функции не получалось загрузить все процессоры.
Конечно, ещё сюда накладывается, что код попал через очень большой PR, который был плохо проревьюен, но не суть.
Вывод: не используйте uuid1 в (хотя его скорее всего никто и так не использует, я увидел впервые за 8 лет).
вообще интересно как ты сделал вывод "не используйте uuid1" а не например "не используйте машины с больше чем 25 ядрами"
DR
V
вообще интересно как ты сделал вывод "не используйте uuid1" а не например "не используйте машины с больше чем 25 ядрами"
Если кому-то нужен uuid1, то мой бывший коллега сделал свою uuid библиотеку по моей находке того, какая uuid1 тормознутая и исправил этот bottleneck в своей имплементации: https://github.com/lorenzosinisi/uuid_tools/
V
Вы в итоге отказались от uuid1 или используете эту либу?
DR
Отказались от uuid1
V
в пользу uuid4?
ŹR
Почему нельзя загрузить mac в память на старте ноды?
ŹR
Хрень какая-то