|
| 2, User294 (ok), 23:37, 15/06/2008 [ответить] [к модератору]
| +/– |
Кстати говоря, если спросить у гугля и именно про рекордно быстрое сжатие с непозорной степенью - окажется что есть (не менее открытые) LZ-based алгоритмы быстрее LZO и даже порой лучше сжимающие.С другой стороны, lzop - нормальная такая замена gzip с похожим на него интерфейсом и со скоростью сжатия на минимальных уровнях сравнимой с производительностью дисковой подсистемы (так что в итоге если через него пропустить порой даже быстрее получится чем просто запись на диск - за счет того что на диск меньше данных записывать).
| | |
| 3, csdoc (ok), 23:41, 15/06/2008 [ответить] [↓] [к модератору]
| +/– |
оптимальным способом сжатия бекапов будет задание правильных приоритетов
через nice / ionice, и максимальный уровень компрессии, bzip2 -9 mysql-dump.sql
| | |
| |
| 4, Даль (?), 13:17, 16/06/2008 [^] [^^] [^^^] [ответить] [к модератору]
| +/– |
>оптимальным способом сжатия бекапов будет задание правильных приоритетов
>через nice / ionice, и максимальный уровень компрессии, bzip2 -9 mysql-dump.sql
Из ит Ъ?
| | |
|
| 5, Volodymyr Lisivka (?), 15:20, 16/06/2008 [ответить] [↑] [к модератору]
| +/– |
 После того, как дам сжат, его надо передать куда-то, причём чем дальше, тем лучше. Скорее всего, это будет передача поверх ssl, значит проблема с CPU снова встанет. Поэтому, лучше всего сжимать gzip-ом с опцией --rsyncable и затем использовать rsync/zsync для передачи.
| | |
|
