Тут интересуются спадом спама Where Has All My Spam Gone?
Одно из обьяснений - русские ботнеты использовались ФСБ для атак на грузию :)
Второй вариант явно хуже - много времени уйдет займет fork + exec - т. е. по времени будет где-то то же самое что и
cd /var/www/user/data/tmp/; find -size 0 | xargs -n2 rm -f >/dev/null 2>&1
Так же -size 0 бессмысленно использовать с rm -r
Короче с точки зрения perfomance (незнаю как надёжности) имеет смысл перейти на reiserfs и/или попробовать поменять io scheduler. Второе не решит проблему длительного бэкапа, но улучшит работу паралельных процессов.
Для сравнения на reiserfs
~ mkdir aaa; cd aaa ; for file in `seq 1 32768`; do touch $file ; done
~ time ls -al | wc -l
32771
real 0m2.263s
user 0m1.980s
sys 0m0.230s
~ cd .. ; time rm -r aaa/
real 0m7.539s
user 0m0.210s
sys 0m7.090s
Вообще нужно давать больше конкретики - а какие-то данные уровня секретарши - "я нажала на кнопку - а у меня ничего не работает". Приходится все угадывать. Супорту секретарш в конце концов платят деньги.
Например может быть длинное имя файла (больше 255 байт) .
не помешало бы для сравнения вывод time tar ..., размер получаемого tar файла и название fs
hdparm, smartctl. Через второе так же можно посмотреть температуру. Так же можно погонять smart тесты - offline и т. д.
А какая скорость диска (и что за диск) покажется через dd if=/dev/<disk> of=/dev/zero bs=4096 count=$[1024*256]
Можно сменить fs - например на reiserfs
Догадаюсь что os - linux 2.6. Ну все нормально - на 2.4 по-моему вообще wa не показывалось - т. е. показало бы что cpu 100% idle.
при wa процессор не работает - просто прцессы ждут ввода-вывода.
И какое отношение это имеет к топику?
Ну пусть, за счёт того что ближайший сервер cdn расположен не в USA а в Амстердаме/Лондоне, rtt уменьшится до 5ms - скорость одной tcp вырастет условно до 13Mb но никак до минимум 25Mb.
В контексте топика без разницы - используется ли несколько паралельных tcp сессий к одному серверу или к нескольким - все равно будет ограничение на скорость одной tcp сесии. И использование cdn никак не решит вопросы топикстартера (точнее эти вопросы он и сам может решить без использования cdn).
А использование cdn решает вопросы:
1. Уменьшения cтоимости.
2. Повышения надёжности.
3. Обслуживания множества одновремённых запросов.
atlantos добавил 30.06.2008 в 19:47
Вот ксати адекватное решение если нужно - http://monalisa.cern.ch/FDT/
Имеет смысл глянуть на http://monalisa.cern.ch/FDT/disk2disk.html - performance test was done using two 1U servers between CERN and MANLAN.
exim умеет авторизацию через dovecot auth socket - достаточно указать путь к нему.
Понаписали четыре страницицы бреда. Читайте rfc на tcp.
По моему по умолчанию в os по умолчанию (winxp) tcp window size 65K. rtt USA<->Austria предположу порядка 10-20ms.
скорость <= 65k/(0.01 - 0.02)s = 3.2 - 6.5 Mb/s
Решения 3:
1. Уменьшать rtt
2. Увеличивать tcp window size. http://www.psc.edu/networking/projects/tcptune - настраивать нужно как на стороне клиента, так и на стороне сервера. Потестировать настройки можно через http://www.google.com/search?q=web+100+ndt
3. Качать в несколько потоков.
Вообще много информации по теме http://www.web100.org.
Сходил по ссылке - особенно понравилось "patent-pending UDP-based protocol" - звучит как патентованое средство
от перхоти. Еще одна быдлоконторка, пытающаяся впарить патентованый быдлсофт для быдлоадминов.
Особенно установливать троянов пользователям для оптимизации tcp стэка.
