История изменений

Знаю. Я сам так жил больше года, мониторя виндовых виртуалок скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилось вынуть половину памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти, на это время на нем не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю; vm.dirty_ratio это процент, но как абсолютное значение ИМХО лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилось вынуть половину памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти, на это время на нем не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю; vm.dirty_ratio это процент, но как абсолютное значение ИМХО лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилась вынуть половину памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти, на это время на нем не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю; vm.dirty_ratio это процент, но как абсолютное значение ИМХО лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилась вынуть половину памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти, на это время на нем не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю, ИМХО vm.dirty_ratio это процент, но как абсолютное значение лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилась вынуть половина памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти, на это время на нем не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю, ИМХО vm.dirty_ratio это процент, но как абсолютное значение лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилась вынуть половина памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти на это время не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю, ИМХО vm.dirty_ratio это процент, но как абсолютное значение лучше чтоб не превышало 1-2GB (для медленного HDD стораджа). А значение vm.dirty_background_ratio не менее чем в три раза меньше.

Знаю. Я сам так жил больше года, мониторя виндовые виртуалки скриптом и тупо поднимая их при падении.

Наткнулся на этом решении случайно, когда понадобилась вынуть половина памяти из сервака на несколько месяцев - и оказалось, что с уполовиненной памяти на это время не упала ни раз ни одна виртуалка.

Проблема еще и в том, что тупые винды давали самые разнообразные BSOD коды при падении. Когда «проблема» по сути сводилась к тому что «диски не отвечают за ожидаемое время».

Не утверждаю что это панацея, но у меня точно сработало. Там был парк винд на kvm с 2003 до 2012 версий, так что не знаю как насчет винд поновее.

Дефолтные сетинги кернела (дебиана, по меньшей мере) для vm.dirty_ratio и vm.dirty_background_ratio годятся для десктопов и большинства серверов, но это (железка с памяти 64G и выше, на которой крутятся древнючие винды) все таки редкая ситуация.

С тех пор всегда уменьшаю, ИМХО vm.dirty_ratio это процент, но как абсолютное значение лучше чтоб не превышало 1-2GB (на HDD стораджи которые медленны). А значение vm.dirty_background_ratio не менее чем в три раза меньше.