А зачем технической поддержке AWS рутинно комментарии на русском? Странно все это, конечно, обычно нужнен вывод стандартных утилит, ключевое слово - воспроизводимость. Что будет делать поддержка получив такой отчет - непонятно, видимо сначала уточнять в какой временной зоне все это происходило time.strftime("%Y-%m-%d %H:%M:%S")
Интересно, спасибо! На Debian 13 OpenSSL подходящий, оставалось только deb с гита разработчиков заполучить. transit как раз по умолчанию максимальный, можно поубавить аппетиты
Уже там не работаю). Это был просто один nvme, без всяких raid{x}. Типовой сценарий виртуалки (zvol's), volblocksize 16k, при генерации нагрузки с fio были совершшенно неадекватные показатели l.avg, iowait, в реальном кейсе при одновременной миграции нескольких вм (4) на сетке даже в 10гбит io на уже работающих на пуле вм вставал колом. В общем-то это и подтвердилось в чистых тестах fio. btrfs на этом же железе c fio тестами показывал <10% io.wait, zfs - больше 60%. сжатие выключено, все ashift учтены ).
Очень интересно, спасибо! Раз уж преисполнились zfs, не тестировали случайно работу direct io с nvme? В предыдущих версия несмотря на primarycache=metadata и secondarycache=metadata все всеравно проходило через code path для ARC. Сейчас нет доступа к свободному железу с nvme, в общем 2.3 не успел протестировать. При многопоточной нагрузке раньше все было печально с загрузкой CPU и iowait, никакие настройки async очередей для чтения записи не помогали (точнее помогали плохо). Обсуждение: https://github.com/openzfs/zfs/pull/10018
Не без этого, но реальный мир это реальный мир, и не я это решение принимал. Как бы там ни было головной боли добавится, хотя бы заново тестировать плейбуки, которые поверх ожидаемого /tmp добавляли маунтпоинты tmpfs, куда SSSD (чтоб в линукс через LDAP-учетки ходить) складывал свои временные файлы. И не ожидал их потери через 10 дней )). by design он их и так в подкаталоги /tmp/* складывал
Ну как, некоторые приложухи могуть иметь привычку в /tmp что-то большое распаковывать, и не всегда убирать за собой. Так что либо память будет этим забита, либо место кончится и своп будет использоваться (если он есть), либо через 10 дней оно удалится (как настроили дебианцы) и приложение чего-то не найдет (много любит в tmp сыпать bitbucket и жира вроде).
last ну это просто удобно смотреть кто последний на сервере хозяйничал
nodatacow должен отключать чексуммы и сжатие, он и compress взаимоисключающие флаги (можно проверить при помощи compsize). Точнее применится только последний из них (смотреть в findmnt). edit: лучше compress-force, на дистрибутиве debian разница ощутимая
Кажется, придумал оптимальный вариант - SSH MITM. Ключи dropbear есть с открытого раздела, и более того, однажды помогал коллеге восстановить пароль сохраненный в SecureCRT похожим образом. Там правда фингерпринт хоста изменился, но этого нам и было надо. А так просто логировать и перенаправлять весь ввод в SSH. profit
А точно это учитывает обе EFI партиции dpkg-reconfigure grub-efi-amd64? КМК активную замаунченную только. В продуктах Proxmox для этих целей используют специальные хуки (ими заведует proxmox-boot-tool)
Тут по легенде "убрал внутренние ip адреса AWS и сменил на наш любимый ya", вместе с циклом и именами переменных (примечание редакции).
А зачем технической поддержке AWS рутинно комментарии на русском? Странно все это, конечно, обычно нужнен вывод стандартных утилит, ключевое слово - воспроизводимость. Что будет делать поддержка получив такой отчет - непонятно, видимо сначала уточнять в какой временной зоне все это происходило
time.strftime("%Y-%m-%d %H:%M:%S")Обнаружился вот такой удобный шаблонизатор для openvpn конфигов, даже подумываю форкнуть и под i2pd допилить чтобы все в одном месте генерить
Пасхалка от разрабов для тех, кому навязывают макс )
Интересно, спасибо! На Debian 13 OpenSSL подходящий, оставалось только deb с гита разработчиков заполучить. transit как раз по умолчанию максимальный, можно поубавить аппетиты
Уже там не работаю). Это был просто один nvme, без всяких raid{x}. Типовой сценарий виртуалки (zvol's), volblocksize 16k, при генерации нагрузки с fio были совершшенно неадекватные показатели l.avg, iowait, в реальном кейсе при одновременной миграции нескольких вм (4) на сетке даже в 10гбит io на уже работающих на пуле вм вставал колом. В общем-то это и подтвердилось в чистых тестах fio. btrfs на этом же железе c fio тестами показывал <10% io.wait, zfs - больше 60%. сжатие выключено, все ashift учтены ).
Наркомания про directio: https://github.com/openzfs/zfs/issues/8381#issuecomment-529174195 , в конце треда параметры которые помогли на zfs 2.x somewhat (iowait 40%), но всеравно не как btrfs на том же чистом тесте с fio. (iowait <10%)
Очень интересно, спасибо! Раз уж преисполнились zfs, не тестировали случайно работу direct io с nvme? В предыдущих версия несмотря на primarycache=metadata и secondarycache=metadata все всеравно проходило через code path для ARC. Сейчас нет доступа к свободному железу с nvme, в общем 2.3 не успел протестировать. При многопоточной нагрузке раньше все было печально с загрузкой CPU и iowait, никакие настройки async очередей для чтения записи не помогали (точнее помогали плохо). Обсуждение: https://github.com/openzfs/zfs/pull/10018
wechat, если получится зарегистрироваться с симки РФ. Партия выдать социальный рейтинг
Не без этого, но реальный мир это реальный мир, и не я это решение принимал. Как бы там ни было головной боли добавится, хотя бы заново тестировать плейбуки, которые поверх ожидаемого /tmp добавляли маунтпоинты tmpfs, куда SSSD (чтоб в линукс через LDAP-учетки ходить) складывал свои временные файлы. И не ожидал их потери через 10 дней )). by design он их и так в подкаталоги /tmp/* складывал
Ну как, некоторые приложухи могуть иметь привычку в /tmp что-то большое распаковывать, и не всегда убирать за собой. Так что либо память будет этим забита, либо место кончится и своп будет использоваться (если он есть), либо через 10 дней оно удалится (как настроили дебианцы) и приложение чего-то не найдет (много любит в tmp сыпать bitbucket и жира вроде).
last ну это просто удобно смотреть кто последний на сервере хозяйничал
/tmp и last/lastb это они засаду подготовили
nodatacow должен отключать чексуммы и сжатие, он и compress взаимоисключающие флаги (можно проверить при помощи compsize). Точнее применится только последний из них (смотреть в findmnt). edit: лучше compress-force, на дистрибутиве debian разница ощутимая
В Halo уже давно предсказали, а может и в симпсонах тоже. https://www.halopedia.org/Mendicant_Bias
Так он не изменится поидее, приватный ключ dropbear сервера в незашифрованном разделе добывается
Кажется, придумал оптимальный вариант - SSH MITM. Ключи dropbear есть с открытого раздела, и более того, однажды помогал коллеге восстановить пароль сохраненный в SecureCRT похожим образом. Там правда фингерпринт хоста изменился, но этого нам и было надо. А так просто логировать и перенаправлять весь ввод в SSH. profit
Круто. Кому интересно как устроены подобные штуки внутри => https://www.youtube.com/watch?v=AptJJsO5qCg . Там еще много всякого проприетарного железа разбирают
Как говорили когда-то на форумах авто.ру - "топик+ник" :D
По памяти, а если отключить ARC либо настройками, либо проще primarycache=metadata secondarycache=metadata?
А точно это учитывает обе EFI партиции
dpkg-reconfigure grub-efi-amd64? КМК активную замаунченную только. В продуктах Proxmox для этих целей используют специальные хуки (ими заведует proxmox-boot-tool)А-а, понял Вас. Я скорее о прочитанных выше опасениях автора думал, и привычку шифровать диски, т.к. у админов гипервизора слишком много возможностей.