Всегда боялся C++ в highload как огня, почитав вас думаю что не зря :)
Поскольку у нас везде чистый С то как правило сталкиваемся со случаями 3-его типа, как верно заметил коллега выше.
Из моей практики самый интересный с долгим расследованием был следующий:
Проксирующие nginx на проекте новости@mail.ru с нашим рекламным модулем иногда отжирали память цеплялись за своп и моментально уходили в нопинг задыхаясь под нагрузкой.
Пытались найти утечку очень долго: снимали coredump в момент перед наступлением ПП, искали утечки valgrind, ничего не помогало. В какой-то момент смогли проверить гипотезу — снятие нагрузки на уже распухшем сервере моментально приводило его в норму по занятой памяти. Значит как таковых утечек в модуле не было в чем же была проблема оставалось непонятно.
Помог вдумчивый анализ кода. Программист выделял буфер для записи ответа рекламного модуля с запасом независимо от реального размера ответа (памяти выделялось сверх необходимого больше где-то в 20 раз). Иногда на редких пиках нагрузки это позволяло зацепиться за своп с последующей смертью сервера. Починили просто — выделять память под ответ когда становилась известна его длина, после получения тела ответа в статический буфер.
Также надо сказать что проблема стала проявляться когда вместо двух проксирующих серверов временно оставили один на что в начале работы по проблеме не обратили внимания.
ну мы почти так и делаем, только nginx кидает короткий пакет на сервер агрегатор который аккумулирует сумму в памяти и скидывает в базу накопившуюся дельту, узкое место — сетевая карта, если она не умеет разбирать очередь в несколько ядер то количество запросов в секунду ограничивается где-то 150000 RPS
странно что вы все пытаетесь апдейтить базу на хит,
достаточно делать счетчик в памяти, инкрементить на хит, а сбрасывать в базу периодически накопившуюся дельту или новое значение, ну а список ссылок — хеш по id в файле поднимаемом по mmap в nginx
такая схема легко держит практически любое кол-во запросов
не совсем так, он обнаружит что «patch already applied» и не создаст коммита
потому что при cherry-pick вы просто пытаетесь наложить патч из указанного коммита на текущую ветку
используют там где принято использовать redis
мем кеш это не база данных, это кеш, упс его базой данных не делает
(вытеснения, потеря данных при плановом перепуске сервера, отсутствие репликации, ограничение на размер хранимых данных размером оперативки)
Поскольку у нас везде чистый С то как правило сталкиваемся со случаями 3-его типа, как верно заметил коллега выше.
Из моей практики самый интересный с долгим расследованием был следующий:
Проксирующие nginx на проекте новости@mail.ru с нашим рекламным модулем иногда отжирали память цеплялись за своп и моментально уходили в нопинг задыхаясь под нагрузкой.
Пытались найти утечку очень долго: снимали coredump в момент перед наступлением ПП, искали утечки valgrind, ничего не помогало. В какой-то момент смогли проверить гипотезу — снятие нагрузки на уже распухшем сервере моментально приводило его в норму по занятой памяти. Значит как таковых утечек в модуле не было в чем же была проблема оставалось непонятно.
Помог вдумчивый анализ кода. Программист выделял буфер для записи ответа рекламного модуля с запасом независимо от реального размера ответа (памяти выделялось сверх необходимого больше где-то в 20 раз). Иногда на редких пиках нагрузки это позволяло зацепиться за своп с последующей смертью сервера. Починили просто — выделять память под ответ когда становилась известна его длина, после получения тела ответа в статический буфер.
Также надо сказать что проблема стала проявляться когда вместо двух проксирующих серверов временно оставили один на что в начале работы по проблеме не обратили внимания.
для верности можно логиниться тут:
secure.mail.ru/
достаточно делать счетчик в памяти, инкрементить на хит, а сбрасывать в базу периодически накопившуюся дельту или новое значение, ну а список ссылок — хеш по id в файле поднимаемом по mmap в nginx
такая схема легко держит практически любое кол-во запросов
потому что при cherry-pick вы просто пытаетесь наложить патч из указанного коммита на текущую ветку
лишнего коммита не будет
мем кеш это не база данных, это кеш, упс его базой данных не делает
(вытеснения, потеря данных при плановом перепуске сервера, отсутствие репликации, ограничение на размер хранимых данных размером оперативки)
приходите ко мне на собеседование :)
лет ему ого сколько