1. Ну я порты свои на фряхе например апгрейжу под найсом, а то иначе браузер подтормаживает. И по работе некоторые вещи сразу под найсом программирую запускать, подсчет контрольной суммы например. Не вижу проблем с этим, удобная штука, прямое решение по ограничению аппетитов cpu-емких задач.
2. Забыл упомянуть, разумеется есть, иначе какой смысл в ограничении на подъем приоритета, если банальный fork/exit может его сбросить, без наследования то…
3. Опять же, не спец по виндам, но в юниксе если любую навороченную систему рендер менеджмента запустить из под скрипта, который себе понизил приоритет (перед запуском оной системы), то выше этого приоритета она не прыгнет (без рутовых прав, конечно).
4. Также напомню про оверхед от виртуалки, который может выражаться в десятках процентов. И про проблемы с пробросом PCI(e) устройств в виртуалку для акселерации рендера.
1. Зачем жестко? Ведь задача стоит — чтобы не мешало никому. Что толку оставлять свободное ядро-два, если за их счет можно соотв уменьшить время рендера? Опять же, а если свободных ядер окажется недостаточно для текущих локальных задач? В случае с понижением приоритета ОС сама отберет ядра у фонового рендера.
С оперативкой да, ограничить не получится, но опять же — а что такого? Если в виртуалке рендер уйдет в своп — кому от этого легче станет. И опять же — если виртуалка не будет зря занимать оперативку (а почем ОС знает, страницы памяти виртуалки уже освободились или ещё понадобятся ?), то для локальных задач её ещё больше получится.
2. В юнихах поднять приоритет себе или другим может только рут. Остальные могут только понизить, и только своему uid-у (что логично). За винду не скажу — не спец.
3. Неужели и cmd-файл из которого будет запускаться эта вся система с пониженым приоритетом нельзя составить?
Ребята, не обижайтесь, но ваше решение создано по принципу «умею пользоваться плоскогубцами — значит и гвозди буду ими же забивать»…
Городить виртуалку ради банального ограничения приоритета фоновой задачи — это сурово. Вы КПД по CPU такого решения хоть посмотрели по тестам?
Увы, не знаю, как под виндой, но под юниксами ваша «задача» решается банальным nice -n 20 (ну и возможно ionice для ограничения приоритета дисковой активности) при запуске демона расчета. Под виндой думаю тоже можно найти решение, хоть бы и на visualbasic-е.
Такая настройка тоже делается один раз и пользователь тоже знать не будет, что на его машине фоновый процесс что-то считает с минимальным приоритетом ))
Деталей сейчас не отпишу, т.к. тот сетап в продакш не пошел.
recordsize=128k
zfs тюнился по разному, под кеш памяти больше половины было выделено точно, игрался с разными настройками через sysctl, а через команду zfs, увы, не очень (
Проблема именно с многопоточной загрузкой, т.е. если тестить в небольшое кол-во потоков бенчмарком — то все ок, сервер отдает столько бендвича, сколько позволяют винты по iops. Но после запуска настоящей нагрузки, когда тысячи браузеров качают файлы одновременно — загрузка винтов зашкаливает, а отдаваемый бендвич сильно падает (скорее всего из-за очень резкого увеличения latency). Я не смог побороть эту деградацию (. Стандартная ufs2 использует ресурс iops винтов куда более экономно — на ней и остановился.
Согласен, такой подход годится для случая, когда данные нужно достать и отдать единоразово, для той же базы данных, или бекап поднять… Но вот, например, если захостить на zfs раздел /usr, где данные нужно регулярно отдавать все новым и новым процессам, то производительность может очень сильно пострадать…
И ещё у меня очень серьезная претензия к многопоточной производительности zfs — async операции это правильно, но шедулер у zfs ужастный. При нескольких сотнях паралельных потоках на чтение размер очереди запросов возрастает катастрофически, что ведет к гигантстким задержкам. Обслужить один поток zfs умеет действительно хорошо, но организовать фотохостинг на ней, например, — дохлый номер (под высокой загрузкой конечно, когда от сервера требуется отдавать фотки тысячам клиентам одновременно).
Спасибо за подробное обьяснение. Немножко странный выбор размеров адресов, ведь все-таки можно было спокойно обойтись 64-х битным полным адресом первую сотню лет…
По поводу копирования данных — я спросил потому что, например, во FreeBSD именно так и происходит (возможно в соляре ситуация другая), и такой подход крайне тормознутый. Технология маппинга страниц отработана десятилетиями, она позволяет очень эффективно кешировать данные файловых систем, особенно страниц с кодом программ, которые не надо копировать от процесса к процессу, например. А так получается, что ZFS требует двойного кеширования (raw block-ов средствами zfs и страниц с данным средствами os)… ;(
Хороший подход, но теперь Вам ещё предстоит поработать над теорией цвета (и света). Дело в том, что коэффициенты смешения нельзя брать пропорциональными просто площади «осколков». Поясню на примере. Если белый пиксел на черном фоне сдвинуть на 50% в сторону, то результирующие два пиксела не будут содержать цвета (128,128,128) ни (127,127,127) — т.к. количество света, излучаемые парой таких серых пикселов, будет отличаться от количества света, излучаемое одним белым пикселом (из-за гаммы), хотя при прецизионном смещении очевидно, что яркость картинки должна была бы остаться полностью прежней.
первый: zfs использует 128-ми битные указатели. Бывает ли что в старших 64-х битах содержатся не нули? Если сейчас нет, то когда (и какие конкретно) наступят условия того, что такая длина указателей окажется востребованной?
второй: когда zfs отдает данные os, маппит ли она страницу своего кеша на страницу, где os хочет видеть данные (либо передает указатель на страницу кеша, а OS делает это самостоятельно), или же только копирует данные из своего кеша в ту страницу, где хочет видеть данные os?
Спасибо, но больше всего интересовал ответ на первый вопрос — насколько прессуют и откуда больше всего идет давление? ) Ведь досеры очень-очень не любят защищающие сервисы и готовы потратиться (а также рисковать отношениями с криминальным кодексом), лишь бы не уменьшался их доход.
>Highload Lab прибыльна
И немножко опасна ;) Сколько раз в месяц к вам поступают серьезные угрозы? В последнее время ещё замечены атаки от провластных субьектов, уверен, они тоже давят на защищающую сторону, не только на атакуемый ресурс…
>Мы принципиально не связываемся с сайтами, содержащими пиратский контент, имеющими нацистскую или порнографическую направленность, с фарма-партнерками и прочей интернет-грязью.
А с пирамидами? Относительно законны, с виду не грязны, и главное, платят хорошо… ))
И ещё вопросик. С защитой https у вас как дела обстоят? Используются ли crypto-ускорители?
Самый первый Descent было кстати удобнее всего играть полностью на клавиатуре — скорость разворота так получалась максимальная, а то мышку приходилось постоянно переставлять по столу, чтобы на большой угол развернуться…
В принципе, избыточное кодирование и восстановление фреймов можно внедрять на любом уровне, вплоть до L1. Собственно, на L1 оно и так широко применяется (но оперирует микрофреймами, типа октетов, кодирующихся 10-ю битами). Выбор TCP уровня вполне оправданный, изменения в нем (теоретически) не затрагивают текущую сетевую инфраструктуру, и в то же время максимально широко охватывают все причины потерь, т.е. на всех уровнях, например, из-за переполнения очереди интерфейса, где L1/L2 ничего не смогут исправить…
Иллюстрация к протоколу на самом деле не совсем корректная, в ней не указывается, что сначала надо передать избыточные данные p0, p0+p1, p0+p1+p2, и только после этого можно выйти на стабильный режим передачи p[i]+p[i+1]+p[i+2], корректируя задетектированные потери новыми избыточными пересылками необходимых сумм. И без соотв поддержки в сетевухах это будет немного напряжно для проца, хотя овчинка выдержки стоит однозначно…
И что-то не понятна ситуация с внедрением NC поверх немодифицированного TCP — что-то сильно маркетингом попахивает, ведь TCP все равно будет пытаться доставить порученный ему поток данных, исправно пересылая потерянные пакеты и занижая соотв скорость, даром что уровень сверху смог бы восстановить поток и без пересылки потерянного пакета.
С одной стороны, куки для того и придуманы, чтобы влиять на генерацию контента, но с другой, содержимое «статического» файла будет определяться не только урлом, но и кукой — костыльно выглядит, как минимум всякое кеширование ломается сходу, и далеко не все cdn для статики смогут такие запросы правильно обработать.
Хорошее решение должно оперировать только урлами. Это сложно, не спорю, надо лезть в движок сайта, одними шаблонами с добавленным JS кодом не обойдешься уже… ((
Поскольку блочные шифры с размером блока 16 бит не очень популярны ;), можно сделать такой самостоятельно с использованием сети Фейстеля. Хотя в данном случае, мне кажется, ещё проще будет просто воспользоваться заранее сгенерированной случайной перестановкой чисел 0,.., 2**L-1 — свойства будут аналогичны. Либо запутать биты несложной комбинацией сдвигов и XOR-в.
Кроме того, думается, что для 2D объекта свойства трансформации будут различаться для случая, когда каждый адрес трансформируется отдельно, и для случая когда трансформации подвергается объединенный адрес длинной в 2L.
А не пробовали применить вместо бит-реверсивной перестановки какое-то другое взаимо-однозначное преобразование и поисследовать? Циклический сдвиг например. Или ещё круче — блочный шифр с размером блока L? Применение шифра к индексу переставит элемент в псевдо-случайное место — шум будет выглядеть совсем по другому.
Вообще-то скорость и склонность к зависанию определяются файловой системой, на которой папка лежит. Ну и немного ещё sysctl-ками.
ls тупит т.к. пытается перед выводом прочесть весь список и отсортировать его, чтобы отключить такой режим надо использовать флаг -f. Ну а дальше для неспешного удаления достаточно затротлить вывод `ls -f` через какую-то тулзу (например через перловый скрипт) и через xargs организовать удаление (100 файлов в 10 секунд): ls -f . | perl -pe 'select(undef,undef,undef,0.1)' | xargs -n 100 rm
Воспаление плечевого сустава. В хроническом состоянии это уже артрит. Когда сгибал сустав в положение натяжения лука — возникала тянущая боль, хоть и не большая, но заметная. Сначала я думал что это от усталости, т.к. занимался часто, но когда после трехмесячного перерыва боль никуда не делась — понял что дело серьезное.
Проколол курс траумеля и мазал фастумгелем — без особого эффекта. Потом другой доктор (тоже лучник, повезло) посоветовал смесь олфен-геля и долобене-геля, вместе с пилюлями нимесил и мидокалм (вдруг кому-то тоже понадобится) и ультразвуковыми процедурами — и таки помогло, а я уже и отчаялся было.
Просто слишком много занимался, и не обратил внимание на болезненные ощущения. Если бы в тире только занимался, то проблем не было бы — в раунде 3 выстрела, да пока за стрелами сходишь — успеваешь отдохнуть. А на балконе стрелял весь колчан, и до щита четыре метра всего — время между раундами существенно меньше, а нагрузка больше… За полчаса занятий на балконе уставал вусмерть. Но я думаю именно эти плотные ежедневные занятия помогли мне достичь уровня МС за такое сравнительно короткое время, т.к. нужен приличный настрел для отработки правильной техники. Просто надо было умерить свой пыл, и стрелять аккуратно, а не на износ.
Соревнования по луку — это совсем-совсем другой опыт, чем одиночная стрельба ) Чтобы показать свой стандартный результат на соревновании — надо очень хорошо себя контролировать и не давать волнению проявляться. Тоже нужна соответствующая практика соревнований в достаточном количестве, так сказать.
2. Забыл упомянуть, разумеется есть, иначе какой смысл в ограничении на подъем приоритета, если банальный fork/exit может его сбросить, без наследования то…
3. Опять же, не спец по виндам, но в юниксе если любую навороченную систему рендер менеджмента запустить из под скрипта, который себе понизил приоритет (перед запуском оной системы), то выше этого приоритета она не прыгнет (без рутовых прав, конечно).
4. Также напомню про оверхед от виртуалки, который может выражаться в десятках процентов. И про проблемы с пробросом PCI(e) устройств в виртуалку для акселерации рендера.
С оперативкой да, ограничить не получится, но опять же — а что такого? Если в виртуалке рендер уйдет в своп — кому от этого легче станет. И опять же — если виртуалка не будет зря занимать оперативку (а почем ОС знает, страницы памяти виртуалки уже освободились или ещё понадобятся ?), то для локальных задач её ещё больше получится.
2. В юнихах поднять приоритет себе или другим может только рут. Остальные могут только понизить, и только своему uid-у (что логично). За винду не скажу — не спец.
3. Неужели и cmd-файл из которого будет запускаться эта вся система с пониженым приоритетом нельзя составить?
Городить виртуалку ради банального ограничения приоритета фоновой задачи — это сурово. Вы КПД по CPU такого решения хоть посмотрели по тестам?
Увы, не знаю, как под виндой, но под юниксами ваша «задача» решается банальным nice -n 20 (ну и возможно ionice для ограничения приоритета дисковой активности) при запуске демона расчета. Под виндой думаю тоже можно найти решение, хоть бы и на visualbasic-е.
Такая настройка тоже делается один раз и пользователь тоже знать не будет, что на его машине фоновый процесс что-то считает с минимальным приоритетом ))
recordsize=128k
zfs тюнился по разному, под кеш памяти больше половины было выделено точно, игрался с разными настройками через sysctl, а через команду zfs, увы, не очень (
Проблема именно с многопоточной загрузкой, т.е. если тестить в небольшое кол-во потоков бенчмарком — то все ок, сервер отдает столько бендвича, сколько позволяют винты по iops. Но после запуска настоящей нагрузки, когда тысячи браузеров качают файлы одновременно — загрузка винтов зашкаливает, а отдаваемый бендвич сильно падает (скорее всего из-за очень резкого увеличения latency). Я не смог побороть эту деградацию (. Стандартная ufs2 использует ресурс iops винтов куда более экономно — на ней и остановился.
И ещё у меня очень серьезная претензия к многопоточной производительности zfs — async операции это правильно, но шедулер у zfs ужастный. При нескольких сотнях паралельных потоках на чтение размер очереди запросов возрастает катастрофически, что ведет к гигантстким задержкам. Обслужить один поток zfs умеет действительно хорошо, но организовать фотохостинг на ней, например, — дохлый номер (под высокой загрузкой конечно, когда от сервера требуется отдавать фотки тысячам клиентам одновременно).
По поводу копирования данных — я спросил потому что, например, во FreeBSD именно так и происходит (возможно в соляре ситуация другая), и такой подход крайне тормознутый. Технология маппинга страниц отработана десятилетиями, она позволяет очень эффективно кешировать данные файловых систем, особенно страниц с кодом программ, которые не надо копировать от процесса к процессу, например. А так получается, что ZFS требует двойного кеширования (raw block-ов средствами zfs и страниц с данным средствами os)… ;(
первый: zfs использует 128-ми битные указатели. Бывает ли что в старших 64-х битах содержатся не нули? Если сейчас нет, то когда (и какие конкретно) наступят условия того, что такая длина указателей окажется востребованной?
второй: когда zfs отдает данные os, маппит ли она страницу своего кеша на страницу, где os хочет видеть данные (либо передает указатель на страницу кеша, а OS делает это самостоятельно), или же только копирует данные из своего кеша в ту страницу, где хочет видеть данные os?
И немножко опасна ;) Сколько раз в месяц к вам поступают серьезные угрозы? В последнее время ещё замечены атаки от провластных субьектов, уверен, они тоже давят на защищающую сторону, не только на атакуемый ресурс…
>Мы принципиально не связываемся с сайтами, содержащими пиратский контент, имеющими нацистскую или порнографическую направленность, с фарма-партнерками и прочей интернет-грязью.
А с пирамидами? Относительно законны, с виду не грязны, и главное, платят хорошо… ))
И ещё вопросик. С защитой https у вас как дела обстоят? Используются ли crypto-ускорители?
Иллюстрация к протоколу на самом деле не совсем корректная, в ней не указывается, что сначала надо передать избыточные данные p0, p0+p1, p0+p1+p2, и только после этого можно выйти на стабильный режим передачи p[i]+p[i+1]+p[i+2], корректируя задетектированные потери новыми избыточными пересылками необходимых сумм. И без соотв поддержки в сетевухах это будет немного напряжно для проца, хотя овчинка выдержки стоит однозначно…
И что-то не понятна ситуация с внедрением NC поверх немодифицированного TCP — что-то сильно маркетингом попахивает, ведь TCP все равно будет пытаться доставить порученный ему поток данных, исправно пересылая потерянные пакеты и занижая соотв скорость, даром что уровень сверху смог бы восстановить поток и без пересылки потерянного пакета.
Хорошее решение должно оперировать только урлами. Это сложно, не спорю, надо лезть в движок сайта, одними шаблонами с добавленным JS кодом не обойдешься уже… ((
Кроме того, думается, что для 2D объекта свойства трансформации будут различаться для случая, когда каждый адрес трансформируется отдельно, и для случая когда трансформации подвергается объединенный адрес длинной в 2L.
ls тупит т.к. пытается перед выводом прочесть весь список и отсортировать его, чтобы отключить такой режим надо использовать флаг -f. Ну а дальше для неспешного удаления достаточно затротлить вывод `ls -f` через какую-то тулзу (например через перловый скрипт) и через xargs организовать удаление (100 файлов в 10 секунд):
ls -f . | perl -pe 'select(undef,undef,undef,0.1)' | xargs -n 100 rmПроколол курс траумеля и мазал фастумгелем — без особого эффекта. Потом другой доктор (тоже лучник, повезло) посоветовал смесь олфен-геля и долобене-геля, вместе с пилюлями нимесил и мидокалм (вдруг кому-то тоже понадобится) и ультразвуковыми процедурами — и таки помогло, а я уже и отчаялся было.
Просто слишком много занимался, и не обратил внимание на болезненные ощущения. Если бы в тире только занимался, то проблем не было бы — в раунде 3 выстрела, да пока за стрелами сходишь — успеваешь отдохнуть. А на балконе стрелял весь колчан, и до щита четыре метра всего — время между раундами существенно меньше, а нагрузка больше… За полчаса занятий на балконе уставал вусмерть. Но я думаю именно эти плотные ежедневные занятия помогли мне достичь уровня МС за такое сравнительно короткое время, т.к. нужен приличный настрел для отработки правильной техники. Просто надо было умерить свой пыл, и стрелять аккуратно, а не на износ.
Соревнования по луку — это совсем-совсем другой опыт, чем одиночная стрельба ) Чтобы показать свой стандартный результат на соревновании — надо очень хорошо себя контролировать и не давать волнению проявляться. Тоже нужна соответствующая практика соревнований в достаточном количестве, так сказать.