Если вы _уверены_, что при j1 работает один поток сборки и всё равно проявляется такое поведение, то попробуйте убрать из командной строки компилятора указание использовать пайпы: -pipe.
Запускал на Celeron, который на базе P3. Но он был чуть сильнее, плюс памяти 512 мегабайт. Но вообще свободная оставалась и слайдшоу не было особо сильного %) Даже со встроенной графикой.
Не ответ на вопрос, но небольшое добавление: переменные, устанавливаемые скриптом (а не логин-шеллом) работают для процесса bash, который выполняет этот скрипт, плюс для всех производных процессов. Соответственно вышеописанным способом нельзя повлиять на переменные среды для всех последующих запущенных процессов.
Значит, что на сокете 5 ещё пока нечего принимать. Нужно с помощью poll/epoll ждать на слушающем сокете, а когда будут данные для чтения — акцептнуть новое соединение. Вообще с таким количеством соединений даже select сойдёт. Если на epoll работает плохо — вернитесь на простой poll.
А вы уверены в таком случае, что нужно менять уже работающую модель? libev — отличная библиотека и хорошо себя показывает даже на огромном количестве одновременно работающих соединений.
SIGBUS можно понимать как SEGFAULT, в смысле обращения к области памяти, в которую лезть нельзя. Обычно кэшеры mmap()'ят файлы в память и развлекаются там.
Если же это не кэш, то… можно откатиться на 5.3 и протестировать там (если сейчас 5.4).
Вы пишите, в каких конфигурациях уже тестировали, чтобы время не тратить на обзор всех вариантов.
Ну, можно просто скомпилировать pv отдельно… Так, ладно, другой способ — посчитать количество файлов в папке (find /home | wc -l), потом запустить tar с ключом -v и stderr перенаправить в файл. Время от времени считать количество строк в этом файле и сравнивать с известным количеством файлов. Можно автоматически %)
barker, да ну… Я по теме программирования прочитал только K&R, всё остальное, что я видел, был код. Больше экспериментов, больше кода. Не могу назвать себя говнокодером.
