Спонсировали. Дима об этом прямым текстом говорил во время какого-то из перегонов между ДЦ. ЕМНИП, в тот же момент, когда объяснял почему не поехали в SDN и почему не поедем в Selectel.
Да, если сторадж доведён до такого состояния, то данный скрипт вас не спасёт, а вот сделать хуже, например, «обломиться» на vmkfstools и при этом удалить оригинальные файлы VM — запросто может, т.к. никаких проверок, как видите, не предусмотрено.
Т.е. вы просто потеряете свою виртуалку. Вообще, не скажу за локальный сторадж, никогда им в vmware толком не пользовался, но на всяких netapp/emc/etc одна из рекомендаций — на нём должно оставаться порядка 20-40% свободного пространства для обеспечения производительности.
Когда-то во времена ESX v3, а может и v4 написал себе подобный скриптик для подобных целей. На современных версиях — не проверял, но думаю, что мало что изменилось.
#!/bin/sh
E_BADARGS=85
if [ $# -ne 1 ]
then
echo "usage : $0 VMname"
echo " VMname - name of VM"
exit $E_BADARGS
fi
VM=$1
VMDK=$VM.vmdk
FLAT=$VM-flat.vmdk
VMDKTHIN=$VMDK-thin
FLATTHIN=$FLAT-thin
vmkfstools -i $VMDK -d thin $VMDKTHIN
rm -rf $VMDK
rm -rf $FLAT
mv $VMDKTHIN $VMDK
mv $FLATTHIN $FLAT
sed -i -e "s/$FLATTHIN/$FLAT/g" $VMDK
Не совсем так. Available to these Subscription Levels:
VS Pro with MSDN (VL)
VS Test Pro with MSDN (Retail)
VS Test Pro with MSDN (VL)
VS Ultimate with MSDN (BizSpark Administrator)
VS Ultimate with MSDN (BizSpark Member)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (NFR FTE)
VS Ultimate with MSDN (Retail)
VS Ultimate with MSDN (VL)
DreamSpark Premium
DreamSpark Standard
MCT Developer Software & Services
MCT Software & Services
Visual Studio Professional (MPN)
VS Premium with MSDN (MPN)
VS Premium with MSDN (MPN)
VS Premium with MSDN (Retail)
VS Premium with MSDN (VL)
VS Pro with MSDN (Retail)
3. Параметр minWorkerThreads — указывает минимальное количество рабочих потоков для каждого процессора, которые могут быть предоставлены немедленно для обслуживания удаленного запроса. Значение по умолчанию — 1.
4. Параметр minIoThreads — указывает минимальное количество потоков ввода/вывода для каждого процессора, которые могут быть предоставлены немедленно для обработки обратного вызова. Значение по умолчанию — 1.
В данном случае следует предостеречь от слишком буквального понимания слова «немедленно». Добавление новой пачки из min[тип_пула]Threads тредов в пул происходит раз в 500 миллисекунд (при дефолтных значениях это 2 потока в секунду).
Поэтому при слишком низких значениях этих параметров холодный старт сервиса (например после ресайклинга апп пула) его прогрев и выход на расчетную производительность может занят значительное время. Подробности можно почитать по ссылке WCF scales up slowly with bursts of work
В случае хостинга WCF сервиса в IIS это приводит к интересным спецэффектам.
P.S. Попытка обнаружить это с помощью профайлера не дает никаких результатов. А вот мониторинг системных счетчиков рисует очень наглядную картину.
Т.е. вы просто потеряете свою виртуалку. Вообще, не скажу за локальный сторадж, никогда им в vmware толком не пользовался, но на всяких netapp/emc/etc одна из рекомендаций — на нём должно оставаться порядка 20-40% свободного пространства для обеспечения производительности.
VS Pro with MSDN (VL)
VS Test Pro with MSDN (Retail)
VS Test Pro with MSDN (VL)
VS Ultimate with MSDN (BizSpark Administrator)
VS Ultimate with MSDN (BizSpark Member)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (MPN)
VS Ultimate with MSDN (NFR FTE)
VS Ultimate with MSDN (Retail)
VS Ultimate with MSDN (VL)
DreamSpark Premium
DreamSpark Standard
MCT Developer Software & Services
MCT Software & Services
Visual Studio Professional (MPN)
VS Premium with MSDN (MPN)
VS Premium with MSDN (MPN)
VS Premium with MSDN (Retail)
VS Premium with MSDN (VL)
VS Pro with MSDN (Retail)
Хотя, конечно, это не вместо реквеста skive, а скорее еще одна функция, которая будет нужна многим из тех кто планирует переезд с MS Exchange.
В данном случае следует предостеречь от слишком буквального понимания слова «немедленно». Добавление новой пачки из min[тип_пула]Threads тредов в пул происходит раз в 500 миллисекунд (при дефолтных значениях это 2 потока в секунду).
Поэтому при слишком низких значениях этих параметров холодный старт сервиса (например после ресайклинга апп пула) его прогрев и выход на расчетную производительность может занят значительное время. Подробности можно почитать по ссылке WCF scales up slowly with bursts of work
В случае хостинга WCF сервиса в IIS это приводит к интересным спецэффектам.
P.S. Попытка обнаружить это с помощью профайлера не дает никаких результатов. А вот мониторинг системных счетчиков рисует очень наглядную картину.