Что происходит -- в памяти создаётся ФС (с некоторыми ограничениями), размером size=1024M, владельцем точки монтирования становится uid=root, gid=root, права выставляются в mode=777.
Как достигается наибольший эффект -- когда кто-то туда пишет/читает часто и мелко вместо диска, например, создаёт/удаляет временные файлы.

Стоит ли этим основным потребителям выделять отдельный /tmp/fast, решать админу. Если есть запросы, промежуточные результаты которых заведомо не влезут в виртуальный диск, либо есть жадные и непрофильные потребители временного пространства в /tmp, всё равно придётся делать несколько временных областей, а тут удобнее сделать приоритетный /tmp/fast, при исчерпании пусть продолжает в общем /tmp, если умеет... Но это уже слабо относится собственно к Slackware

3-е поле -- тип ФС. tmpfs.

да? а это не как bind or move считается?

ЗЫЖ none должно быть в третьем поле, а не в первом.

man fstab
1-е поле -- что монтировать. tmpfs.
2-е поле -- куда смонтировать. /tmp или куда нужно.
3-е поле -- тип ФС. tmpfs.

none /tmp tmpfs mode=777,size=1024M,uid=root,gid=root 0 0

вообще-то правильно, что с недоверием. mode=0777 это дыра. Должно быть 1777. По части size не в курсе, это вам оно виднее.
ИЧСХ, база лежит совсем не там. База лежит в /var/lib/mysql (у меня во всяком случае)

ЗЫЖ none должно быть в третьем поле, а не в первом.

none /tmp tmpfs mode=777,size=1024M,uid=root,gid=root 0 0 

Если кто сталкивался, дайте совет.  smile

Уже мониторил логи, именно из них и выловил ошибку при падении php, кстати она опять появилась, но уже не так часто и меньше, вот так выглядит лог ошибки httpd:
Консоль:

[Thu Jun 02 16:58:37 2011] [notice] SIGHUP received.  Attempting to restart
[Thu Jun 02 16:58:38 2011] [notice] Digest: generating secret for digest authentication ...
[Thu Jun 02 16:58:38 2011] [notice] Digest: done
[Thu Jun 02 16:58:39 2011] [notice] Apache/2.2.15 (Unix) DAV/2 PHP/5.2.17 configured -- res

где ошибка? нет никакой ошибки. сигнал SIGHUP принят, вот он конфиг и перечитал. ИЧСХ - успешно.

именно при выполнении этого запроса. а вовсе не все 24 часа.

не знаю...

ну ещё-бы, ибо 300 == 5 минут.
http://php.net/manual/ru/info.configuration.php
а вот что там у вас тормозит в скрипте - я не знаю. Не думаю, что надо валить всё на php - у меня были все его версии, и таких глюков я не наблюдал. И апач тут тоже не причём.

ИМХО это наверное вовсе не из-за php/httpd.

Не, изначально именно php падало, так как переставала отрабатывать на странице- открывалась белая страница, с хаотично раскиданными надписями.

Уже мониторил логи, именно из них и выловил ошибку при падении php, кстати она опять появилась, но уже не так часто и меньше, вот так выглядит лог ошибки httpd:

Были такие мысли, но в этом же случае mysql должен нагружать память или процессор, а он ведёт себя вполне нормально и стабильно:

Особо серьёзных требований нет, только к версии php и пары изменений в самом файле:

max_execution_time = 30
 max_execution_time = 300
date.timezone = Europe/Moscow 
post_max_size = 32M
max_input_time = 600

Они не падают Просто когда пытаешься просмотреть отчёт, либо добавить новый хост, то приходится ждать открытие страницы минимум 10-15 минут, бывает соединение сбрасывается, мотивируя простоем.