AA
удаленные кеды… месье знает толк в извращениях
Size: a a a
2019 January 28
DM
На машине соединенной напрямую гигабитом gtk2 приложение может и сносно будет работать. А так я с работы на домашней тачке уже ничего запустить не могу - 100Mb в полку и несколько секунд обновление окна. И думается что с новыми тулкитами все еще хуже
DM
А зачем вы dbus настраиваете я не понял - во первых, там изначально сетевая прозрачность, во вторых он не нужен для работы - у меня dbus-* принципиально удалены
DM
Бинарники всмысле
M
Друзья, проконсультируйте меня по дисковым операциям, а именно записи на диск.
Я правильно понимаю, что и в UFS2 + SU и ZFS данные пишутся не сразу, а буферизируются для обработки на уровне системы? Вообще задержки там какого порядка могут быть?
Я правильно понимаю, что и в UFS2 + SU и ZFS данные пишутся не сразу, а буферизируются для обработки на уровне системы? Вообще задержки там какого порядка могут быть?
DM
Вообще любого, в зависимости от настроек. Вас это не должно волновать, поскольку есть вызов fsync()
MZ
Друзья, проконсультируйте меня по дисковым операциям, а именно записи на диск.
Я правильно понимаю, что и в UFS2 + SU и ZFS данные пишутся не сразу, а буферизируются для обработки на уровне системы? Вообще задержки там какого порядка могут быть?
Я правильно понимаю, что и в UFS2 + SU и ZFS данные пишутся не сразу, а буферизируются для обработки на уровне системы? Вообще задержки там какого порядка могут быть?
https://www.freebsd.org/doc/handbook/configtuning-disk.html#soft-updates - "even a minute" :)
DM
vfs.zfs.txg.timeout по умолчанию 5, я выкручивал в 30
M
Меня волнует это в разрезе сравнения хранения условно временных данных, к примеру, сессий в виде файлов и в SQL.
Я так понимаю что разницы между FS и DB быть не должно особенных ввиду того что и там и там всё идёт ассинхронно.
Я так понимаю что разницы между FS и DB быть не должно особенных ввиду того что и там и там всё идёт ассинхронно.
M
В память попало и адьос. Дальше не дело приложения.
AF
ну... у SQL как бы транзакции и оно или проехало или нет, а куда и как это уже тонкости, а вот файлы, там же фартуна, без всяких FS сюпризов
AF
да и вообще у вас сервир или где, чтоб думать, запишется или не повезёт
DM
Нет конечно. Всё что пишет в ФС должно сделать fsync() чтобы убедиться что данные упали на диск и только после этого вернуть результат клиенту.
MZ
Меня волнует это в разрезе сравнения хранения условно временных данных, к примеру, сессий в виде файлов и в SQL.
Я так понимаю что разницы между FS и DB быть не должно особенных ввиду того что и там и там всё идёт ассинхронно.
Я так понимаю что разницы между FS и DB быть не должно особенных ввиду того что и там и там всё идёт ассинхронно.
так, давай тогда предметно - какой СУБД и прочие. БД защищают wal/redo логами которые fsync-аются. Так что коммит транзакции без fsync-а - деньги на ветер :)))
DM
БД делают fsync при закрытии транзакции
M
ну, к примеру, стадартный InnoDB в MySQL и клонах. Понятно что там binlog и всё такое.
M
БД делают fsync при закрытии транзакции
Да, всё равно memory cache сначала. То есть никто диски не ждёт, конечно
DM
Внутреннее устройство вообще не должно вас волновать. Важно что когда вы закрыли транзакцию, данные уже на диске.
MZ
извиняюсь за троллинг, а у вас какие диски? SAS/SATA? SSD/HDD? :)
M
Меня волнует как это отражается на производительности клиентского софта. "That is the question"