Здесь дело не в магазинах и т.п., а в том, что в последние месяцы из студии выпускается практически никакое количество серьезных работ. Для массовости делается всяко-разно фигня типа дизайна чего-то мелкого для себя.
Удивляться здесь нечему совершенно. Когда ваш сайт начал напрягать сервер — его, чтобы совсем не отключать, перенесли в отстойник. Это обычная практика, которую практикуют многие хостеры.
Дело в том, что часто бывает, что клиенты не хотят разбираться, почему их софт грузит сервер. Причем не то чтобы оперативно, а вообще разбираться — мол, раньше все работало, что вы сделали, верните все на место :)
Но сайт ведь создает нагрузку — мешает соседям. Поэтому вменяемый хостер либо отключит сайт, либо перенесет его в отстойник и, естественно, что одного клиента-грузчика спрашивать никто не станет в сете получения ответа через долгое время или не получения его вовсе. Хостеру нужно обеспечить комфортную работу остальным 500-1000 клиентам на том же железе :)
P.S. Пользоваться другой папкой для сохранения сессий можно — рад что в вашем случае это помогло, но в современных системах /tmp обычно монтируется как tmpfs. Это фактически аналог ram drive. Число файлов в папке при этом не долно играть особой роли. А хранение сессий на физическом диске — это наоборот может быть медленнее.
В качестве какой задачи? :) Задача подразумевает достижения определенного результата — например, добиться стабильного выведения BINGO или наоборот.
Объяснить почему и будет ли в текущем варианте — это может сделать любой, кто глубоко разбирался в подобных вещах на уровне CPU/кэшей и т.п.
Тот, для кого синхронизация ограничивается *_mutex_lock() или *CriticalSection() — никогда не сможет объяснить, почему так происходит, т.к. у него подобных проблем просто не должно возникать ;)
Те, кто в этом разбиается на достаточном уровне — обычно не пользуются готовыми решениями, которые представляет компилятор, а пишут свой код на ASM под конкретную платформу, которую необходимо поддерживать. У нас такое реализовано для x86 и PPC.
Ну и по крайней мере volatile это уж точно не барьеры, а совет копилятору, в каком порядке производить вычисления. На платформе отличной от x86 барьеры необходимо выставлять ручками в коде :)
У вас не поставлена задача разбора проблемы, т.к. нет задания, что необходимо сделать в итоге (как исправить). Есть только вопрос — будет ли выводиться и почему без требований привести это к какому-либо предсказуемому результауту :)
Ответ — да, выводиться будет, вне зависимости от того, какой поток стартует первым, но выводиться будет не всегда.
Есть заковыка в том, что копирование в test_xx из xx осуществляется с противоположных концов, а запись единиц в xx происходит в обратном порядке.
Синхронизация (весьма оригинальная) приводит к тому, что лупы выполняются одновременно, а кроме синхронизации на x86 есть еще cache_line_size, который также влияет на доступ.
Для того, чтобы достичь стабильного результата синхронизация должна быть другой.
Суть в том, что любому технически грамотному пользователю видно, что сетевая нейтральность локальными кэшами вообще никак не затрагивается. Скорее наоборот — каналы освобождаются для других сервисов. Кто-то из иницииаторов шумихи поднял визг на пустом месте.
Хорошо хоть в россии пока нигеров ленивых и тупых нет на каждом шагу, которые мечтают в автобусе вас спровоцировать на что-либо, что потянет на суд и компенсацию в их пользу.
Изначально я думал, что речь идет как раз о шаред памяти, но почитав и вникнув понял, что речь идет совсем о другом.
Как я уже написал — «аллокатор который будет заточен под стратегию использования в памяти nginx» — эта фраза с моей точки зрения бессмыссленна в отношении malloc, который в nginx используется в основном на фазе инициализации сервера для не-shared памяти.
Советую все же почитать материалы по аллокаторам и изучить современные подходы к задачам. А то глядя на выбор аллокатора на глаз на основе «на глаз лучше рвет всех obsd-like» заставляет сомневаться, что вы понимаете разницу между свойствами различных типов аллокаторов и задачами для которых они предназначены.
С чего вы взяли, например, что ptmalloc из linux хуже BSD-шного, где используется принцип локинга, который не дружит с SMP в плане маштабируемости?
А ведь масштабируемость для подобных серверов главное — не так ли?
Забыл про пункт 3) написать, что работа идет таким образом с shared памятью. В связи с чем любая оптимизация системного маллока для nginx теряет смысл, в принципе.
1) пред-обработанные события складываются в очередь, которая разгребается многими воркерами
2) воркеры выполняются на разных cpu (если их много)
3) обработка последовательных событий для одного и того же соединения может таким образом выполняться не только в контекстах разных CPU но и разных процессов
В реальной жизни обычный malloc, который выделяет память только в рамках текущего процесса — к обработке соединений в nginx не имеет особого отношения.
Если есть реальное желание что-то ускорить — займитесь тем, что реально используется.
А так, если думаете, что я тут сказки рассказывают — посмотрите в коде nginx, где реально используется обычный malloc :) Судя по тому, что вы написали в статье — результаты вас удивят.
Под незаточен я имел ввиду — не сильно оптимизирован, но вообще-то умеет. По крайней мере выравнивание размера структур до cache line size кое-где присутствует.
В nginx более правильно задать другой вопрос — зачем там вообще что-то делать с malloc, если там для основных рантайм вещей используется свой код (а не системный generic use allocator)?
Если вы это все на linux делали, то результат потребления памяти вполне может быть понятен. По крайней мере нужно знать — что лежит за тем, что использовалось. В linux libc — ptmalloc на базе lea — он весьма неплох и для generic use, и для SMP, и для быстродействия.
Да за счет per cpu/thread/process куч он менее экономно относится к памяти, но за быстродействие нужно платить :)
Что касается различных slab и подобных аллокаторов, которые используют память компактно — они (по крайней мере в моих тестах) все медленнее.
А на основе чего вы выбрали аллокатор для замены? Исследовали какие-либо материалы на тему? :) Почему именно это аллокатор, а не другой? Где сравнения с более современными аллокаторами?
P.S. Когда быстродействие отличается незначительно, то можно сделать выбор в сторону более компактного аллокатора, а не более быстрого — зачастую это понятия несовместимые :)
P.P.S. Еще более интересно каким образом измерялось «потребление памяти около 40 мегабайт на каждый worker процесс» в условиях copy-on-write и разделяемой памяти между процессами? :)))))
Дело в том, что часто бывает, что клиенты не хотят разбираться, почему их софт грузит сервер. Причем не то чтобы оперативно, а вообще разбираться — мол, раньше все работало, что вы сделали, верните все на место :)
Но сайт ведь создает нагрузку — мешает соседям. Поэтому вменяемый хостер либо отключит сайт, либо перенесет его в отстойник и, естественно, что одного клиента-грузчика спрашивать никто не станет в сете получения ответа через долгое время или не получения его вовсе. Хостеру нужно обеспечить комфортную работу остальным 500-1000 клиентам на том же железе :)
P.S. Пользоваться другой папкой для сохранения сессий можно — рад что в вашем случае это помогло, но в современных системах /tmp обычно монтируется как tmpfs. Это фактически аналог ram drive. Число файлов в папке при этом не долно играть особой роли. А хранение сессий на физическом диске — это наоборот может быть медленнее.
Объяснить почему и будет ли в текущем варианте — это может сделать любой, кто глубоко разбирался в подобных вещах на уровне CPU/кэшей и т.п.
Тот, для кого синхронизация ограничивается *_mutex_lock() или *CriticalSection() — никогда не сможет объяснить, почему так происходит, т.к. у него подобных проблем просто не должно возникать ;)
Ну и по крайней мере volatile это уж точно не барьеры, а совет копилятору, в каком порядке производить вычисления. На платформе отличной от x86 барьеры необходимо выставлять ручками в коде :)
Ответ — да, выводиться будет, вне зависимости от того, какой поток стартует первым, но выводиться будет не всегда.
Есть заковыка в том, что копирование в test_xx из xx осуществляется с противоположных концов, а запись единиц в xx происходит в обратном порядке.
Синхронизация (весьма оригинальная) приводит к тому, что лупы выполняются одновременно, а кроме синхронизации на x86 есть еще cache_line_size, который также влияет на доступ.
Для того, чтобы достичь стабильного результата синхронизация должна быть другой.
Как я уже написал — «аллокатор который будет заточен под стратегию использования в памяти nginx» — эта фраза с моей точки зрения бессмыссленна в отношении malloc, который в nginx используется в основном на фазе инициализации сервера для не-shared памяти.
Советую все же почитать материалы по аллокаторам и изучить современные подходы к задачам. А то глядя на выбор аллокатора на глаз на основе «на глаз лучше рвет всех obsd-like» заставляет сомневаться, что вы понимаете разницу между свойствами различных типов аллокаторов и задачами для которых они предназначены.
С чего вы взяли, например, что ptmalloc из linux хуже BSD-шного, где используется принцип локинга, который не дружит с SMP в плане маштабируемости?
А ведь масштабируемость для подобных серверов главное — не так ли?
1) пред-обработанные события складываются в очередь, которая разгребается многими воркерами
2) воркеры выполняются на разных cpu (если их много)
3) обработка последовательных событий для одного и того же соединения может таким образом выполняться не только в контекстах разных CPU но и разных процессов
В реальной жизни обычный malloc, который выделяет память только в рамках текущего процесса — к обработке соединений в nginx не имеет особого отношения.
Если есть реальное желание что-то ускорить — займитесь тем, что реально используется.
А так, если думаете, что я тут сказки рассказывают — посмотрите в коде nginx, где реально используется обычный malloc :) Судя по тому, что вы написали в статье — результаты вас удивят.
В nginx более правильно задать другой вопрос — зачем там вообще что-то делать с malloc, если там для основных рантайм вещей используется свой код (а не системный generic use allocator)?
Если вы это все на linux делали, то результат потребления памяти вполне может быть понятен. По крайней мере нужно знать — что лежит за тем, что использовалось. В linux libc — ptmalloc на базе lea — он весьма неплох и для generic use, и для SMP, и для быстродействия.
Да за счет per cpu/thread/process куч он менее экономно относится к памяти, но за быстродействие нужно платить :)
Что касается различных slab и подобных аллокаторов, которые используют память компактно — они (по крайней мере в моих тестах) все медленнее.
P.S. Когда быстродействие отличается незначительно, то можно сделать выбор в сторону более компактного аллокатора, а не более быстрого — зачастую это понятия несовместимые :)
P.P.S. Еще более интересно каким образом измерялось «потребление памяти около 40 мегабайт на каждый worker процесс» в условиях copy-on-write и разделяемой памяти между процессами? :)))))