Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
Control plane отправляет запрос на 2 vCPU и 4 ГБ RAM, но когда ВМ начинает активно нагружаться, шедулер Linux отдаёт ей всё свободное время.
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
На нетбуке с 4ГБ памяти разменивал процессор на память при помощи zramswap. Отдал половину памяти под это дело. Работало нормально и точно будет работать, в отличие от вероятности запустить vramfs сейчас.
И как это я звонил через psi+ году аж в 2010-м? Наверное, через установку пакета с плагинами. См. хотя бы https://sourceforge.net/projects/psiplus/ — видеозвонки указаны явным образом. Впрочем, тогда не зашло и сейчас не зайдёт — вообще не люблю звонки...
Правильно! Ибо незачем их собирать ваще все, когда достаточно сделать запрос к оператору и не более, чем через (не помню, сколько по регламенту) должен быть исчерпывающий ответ по всем соединениям данного ip и ваще всё, что надо. За счёт оператора, конечно же.
Самой оси хватало и 8. Апгрейдился из-за офиса когда-то. Вот с ним на 8 уже не жизнь.
Ну не летала она на 4МБ, не летала. Вот на 8 — было очень даже неплохо. Потом, правда, приложения стали кушать.
Кстати, альт всё ж неплох, если достаточно того, что есть в дистрибутиве.
Только в госучреждениях и приравненных к таковым... У остальных выбор пошире будет. У нас, к примеру, чистый дебиан обычно.
А тут два основных варианта — либо нечто RHEL-подобное, либо нечто с deb-пакетами и apt. Остальное слишком мелкое по занимаемой доле ;-)
P.S. Даёшь холивар! :-)
Таки я в курсе про cgroups, им и делали в своё время.
Тут, скорее, надо более-менее автоматически понижать приоритет жрущих и возвращать обратно, когда перестают, а не тупо ограничивать проц. Ибо если никто на процессор не претендует — пусть кушают, сколько получится. Ну это если нет возможности организационно разделить редких крупных потребителей, которым можно отдать ядра без соседей и мелочь, где и десяток виртуальных ядер на одно реальное норма.
Из текста далеко не ясно, что речь про оверселлинг по процессору. Лично я понял это как "отдаём внутрь вм все ядра, ограничиваем только снаружи, потому что по-другому не умеем" и никак иначе.
Ну и, кстати, борьба с легитимной нагрузкой на вм путём уменьшения реально отданного процессорного времени с точки зрения клиента выглядит странно (из заметного, кроме уменьшения быстродействия от ожидаемого — рост steal). Проходили лет 10-15 назад...
Как вы сумели такого добиться? Вот тупо взял qemu без libvirt, указал нужное количество памяти через -m и число ядер через -smp, нагрузил числом активных процессов раза в два побольше ядер, чем выдал — жрёт столько, сколько указано ядре, а не сколько процессов.
В чём глюки были? А то у меня пока только одновременное редактирование одного файла в оффлайне было и это скорее мой косяк, а не syncthing.
Не встречал таких. Обязательно насыплют всякого, не имеющего отношения к основной функции.
Как глюки проявлялись? И на каком объёме числа файлов/гигабайтов?
А то непонятно, мне готовиться к переезду или пока время терпит...
Если есть сайт или вдс — у хостинг-провайдера сайта. Те же нетангелы дают десяток ГБ почты.
На нетбуке с 4ГБ памяти разменивал процессор на память при помощи zramswap. Отдал половину памяти под это дело. Работало нормально и точно будет работать, в отличие от вероятности запустить vramfs сейчас.
https://wiki.archlinux.org/title/Swap_on_video_RAM — я не знаю, насколько это актуально, но в арчвики найдётся практически всё.
А вообще, возможность использования видеопамяти в качестве обычной хотели ещё во времена DOS...
UPD: таки да, там vramfs и невозможность использования с проприетарными драйверами.
И как это я звонил через psi+ году аж в 2010-м? Наверное, через установку пакета с плагинами. См. хотя бы https://sourceforge.net/projects/psiplus/ — видеозвонки указаны явным образом. Впрочем, тогда не зашло и сейчас не зайдёт — вообще не люблю звонки...
Вот как раз яндексго и т-банк лучше бы не приводить в пример хорошего супераппа — понапихали всякого г в приложение, при этом нужное хрен найдёшь...
Правильно! Ибо незачем их собирать ваще все, когда достаточно сделать запрос к оператору и не более, чем через (не помню, сколько по регламенту) должен быть исчерпывающий ответ по всем соединениям данного ip и ваще всё, что надо. За счёт оператора, конечно же.
Даже если не выкинули, то 10Г имеется давно и каким-то особым преимуществом не является.
Иногда "нет технической возможности" ©
Они а) появились чуть раньше планшетов, б) во время одновременного существования были СИЛЬНО дешевле. А так — да, не лучше.