The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Выпуск CRIU 4.2, системы для сохранения и восстановления состояния процессов в Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск CRIU 4.2, системы для сохранения и восстановления состояния процессов в Linux"  +/
Сообщение от opennews (??), 14-Ноя-25, 09:28 
После шести месяцев разработки опубликован выпуск инструментария CRIU 4.2 (Checkpoint and Restore In Userspace), предназначенного для сохранения и восстановления процессов в пространстве пользователя. Инструментарий позволяет сохранить состояние одного или группы процессов, а затем возобновить работу с сохранённой позиции, в том числе после перезагрузки системы или на другом сервере без разрыва уже установленных сетевых соединений.  Код проекта написан на языке Си и распространяется под лицензией GPLv2. CRIU применяется в таких системах управления контейнерами, как OpenVZ, LXC/LXD и Docker. Необходимые для работы CRIU изменения включены в основной состав ядра Linux...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64248

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 14-Ноя-25, 09:28   +1 +/
Использую в продуктивной системе, здоровья проекту!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #10

2. Сообщение от Жироватт (ok), 14-Ноя-25, 09:50   +/
Попробовал. Хм...Джава-стек сумело корректно сохранить и восстановить
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3

3. Сообщение от Аноним (3), 14-Ноя-25, 09:54   +/
А чего там восстанавливать? Только с видеокартами были сложности. Лучше расскажи, какое практическое применение есть? Я могу придумать только продолжительный рендер без возможности прервать и срочное обновление.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7

4. Сообщение от Шарп (ok), 14-Ноя-25, 09:54   +/
>без разрыва уже установленных сетевых соединений

Это невозможно. Другая сторона в сетевом соединении увидит разрыв. Если есть данные прикреплённые к сессии, то они сбросятся.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #9

5. Сообщение от trolleybus (?), 14-Ноя-25, 09:59   –4 +/
> Устранено целочисленное переполнение в функции pagemap_len()

А вот это типично сишная проблема. Многие тупо не парятся и везде пишут int, когда даже стандартом не определено, сколько точно байтофф оно занимает, ибо architecture dependent. Про знаковые/беззнаковые вообще молчу. А использовать всякие uint32_t не хотим, это ненужное ненужно.

Даже в расте такой номер не пройдет, если только специально не поиздеваться.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #11

6. Сообщение от Аноним (3), 14-Ноя-25, 10:18   +1 +/
Другая сторона только отвалится по таймауту. Если не успеет, то всё будет как будто у нас тут небольшой свопинг приключился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

7. Сообщение от Жироватт (ok), 14-Ноя-25, 10:29   +/
На старых версия не всегда корректно работал с большим количеством JNI-вызовов, ведь должны захватываться и они.
> Лучше расскажи, какое практическое применение есть?

Рендер, расчеты.
На билдферме может выполняться сборочный процесс.
Иногда просто нежелательно тушить процесс

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

8. Сообщение от Пыщь (?), 14-Ноя-25, 10:32   +2 +/
Понравилась цитата защищавшего расто-операторов, суну сюда: "Это вы себе что-то придумывете. А люди обучаются, исправляют ошибки, получают знания и удовольствие."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

9. Сообщение от Аноним (9), 14-Ноя-25, 10:33   +/
Там специальные подпорки в ядре, позволяющие реконструировать внутреннее состояние сокета без использования вызовов сокетного апи, поэтому сокет будет восстановлен точно в том же состоянии, и если удалённая сторона не затаймаутилась - то она ничего не заметит, закрытия сокета и посылки FIN не происходит, а после разморозки трафик едет дальше, как ни в чём не бывало.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

10. Сообщение от привет (ok), 14-Ноя-25, 10:57   +/
продуктовой (с) тех-лид ВТБ
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

11. Сообщение от Медведь (ok), 14-Ноя-25, 11:43   +/
> А вот это типично сишная проблема.

Бред сивой кобылы. Такое возможно в любом  ЯП, где целые занимают фиксированный размер в памяти. Ржа тоже вполне себе подвержена ошибкам из-за выхода за допустимый диапазон значений.

Забавно, ржавозависимые при каждом баге в растокоде упрекают всех, что от их драгоценной ржи требуют чего-то, чего ржа не обещала, но сами не могут определиться с тем, чего же она все-таки обещала ;)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

12. Сообщение от Catwoolfii (ok), 14-Ноя-25, 12:00   +/
эту штуку могли бы использовать в proxmox для живой миграции контейнеров lxc
Ответить | Правка | Наверх | Cообщить модератору

13. Сообщение от Аноним (13), 14-Ноя-25, 12:16   +/
> после разморозки трафик едет дальше, как ни в чём не бывало.

даже через неделю?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру