Это хорошо
Шлют статистику не броузеры, а тулбары.
Хромиум статистику не шлет, а хром (т.е. тот, который у всех стоит) шлет
Я лично общался с одним западником который в такой конторе работает, покупают у провайдеров неперсонализированные (т.е. без имени-фамилии) персональные данные типа пол, возраст, профессия и т.д. и перепродают после обработки
выдает. только алгоритм следующий
1) получить список файлов
2) обработать в соответствии с флагами
3) выдать обработанный список.
т.е. с флагами -f (-U) список файлов просто не сортируется, но в любом случае составляется.
вот код на пхп для удаления миллионов файлов без потребления памяти да и процессора:
<?php
$dir = '/directory/in/question';
$dh = opendir($dir)) {
while (($file = readdir($dh)) !== false) {
unlink($dir . '/' . $file);
}
closedir($dh);
?>
взято отсюда http://serverfault.com/questions/183821/rm-on-a-directory-with-millions-of-files
find bin-tmp1/sess_000* > find.log
черт, правильно, ему же прошерсить надо весь список файлов.
ну вот здесь чел пишет как он удалил порядка 100-150 млн файлов
http://blogs.perl.org/users/randal_l_schwartz/2011/03/perl-to-the-rescue-case-study-of-deleting-a-large-directory.html
причем там написано почему ни ls, ни rm, ни find ему не помогли - они все строят список файлов сначала, что и пожирает всю память.
PS прикинуть размер списка файлов (т.е. сколько памяти потребуется) можно так ls -dl
как я понимаю, память жрется потому что создается список всех файлов в памяти.
попробуйте поставить фильтр, чтобы ограничить кол-во файлов на удаление, напр. сначала удалить все, что начинается на 'a', потом на 'b' и т.д., или что-то подобное, в зависимости от структуры названий ваших файлов.
скорее всего, при вашем кол-ве файлов, придется фильтровать не по одному символу, а по два, т.е. 'aa', потом 'ab' и т.д.
попробуйте ручками, если память не будет пожираться, значит скрипт писать надо.
Vertex 2, год на рабочей станции, пока живет.
Но скорость хоть и в разы выше чем сата-диск, но сильно ниже заявленной производителем на тестах.
или раздел отдельный под tmp организовать и монтировать туда.
а потом грохать весь раздел сразу.
самый большой недостаток SSD - они очень плохо относятся к записи. Именно запись их убивает, причем убивает достаточно быстро, поэтому нагруженная на запись БД - это самая худшая область применения для них. Причем большие буфера из памяти в этом режиме не помогут совершенно.
то, что там скорости высокие - существенная правда, но очень сильно зависит, последовательное это чтение или случайными блоками по 4К, разница в скорости очень сильная.
еще совсем недавно у них летели контроллеры очень частно, а те часы наработки на отказ указывают наработку на отказ собственно ячеек памяти, а не контроллера. В последнее время отказы контроллеров случаются реже, но все еще случаются.
кстати, заявленная скорость - это пока ССД новая, как только объем записываемой инфы случается больше чем объем самой ССД (т.е. перезапись), скорость деградирует, и чем дальше, тем больше.
В общем, вещь достаточно ненадежная для сервера.
из ОС - вин7 из коробки оптимизирована под ССД, она их знает, определяет и настраивается под них, линукс допиливать надо.
тому как не попадать под АГС.
что тут непонятного?
Действительно староват, поэтому слишком неитересно.
Но не суть. Вопрос в другом - что тестировалось? Веб-сервер или пхп? Если веб-сервер, то при чем здесь пхп в тесте? Ведь даже в тесте, который вы привели, пишут, что статика не тестировалась, co статикой все намного хуже. Как вы прокоментируете фразу "если убрать обработку статики и всего прочего (напр с помощью ngnix)"?
Ваша проблема в том, что вы не читаете что вам пишут. А пишут вам все время одно и то же - nginx выигрывает с хорошим отрывом у апача на статике и на большом количестве соединений. Если вы в тест включаете пхп - все, статики нет, весь выигрыш нивелирутся тормознутостью пхп. Если тест производится на сотне соединений - разницы нет, что апач что nginx, современное железо отлично справляется с сотней-другой-третей ниток.
