daitepiva

Смотрите ошибки в логах веб-сервера или PHP. Насчёт PHP версии 5.6 вы, возможно, погорячились - есть вероятность, что форум и не должен работать с этой версией и выше.

Так может придумаете своё доменное имя, например, forum.my, пропишете его в настройках форума, а потом в файле hosts: 127.0.0.1 forum.my www.forum.my ping forum.my PING forum.my (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.034 ms 64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.039 ms ^C На линуксе этот файл лежит в папке /etc Где этот файл находится в Винде я точно сказать по памяти не могу, где-то в c:\windows\system32\drivers\etc

1. Думаю, что без модификаций не обойтись. 2. Надо смотреть логи веб-сервера. 3. Как раз писал про это в соседней теме: Админка - Настройки безопасности - Удалять неактивированные учетные записи после X дней. Правда тут указываются дни, а не часы. 4. Насколько я знаю, использование крона необязательно. Раз только некоторые задачи не выполняются - значит сам по себе планировщик работает. А вы как определяете, что задачи не выполняются? Смотрите "Журнал задач"? Там ещё есть странная штука - планировщик работает по часовому поясу UTC, по крайней мере у меня, т.е., например, если у вас пояс UTC+3 и уже 15 часов, то планировщик считает, что только 12.

1. Непонятно в чём реклама заключается? Вот зарегился юзер с неправильным емейлом, регистрацию не подтвердил, а где видна эта реклама? 2. Пользователи, не подтвердившие регистрацию, должны удаляться и так, время до удаления здесь: Админка - Настройки безопасности - Удалять неактивированные учетные записи после X дней. Правда тут указываются дни, а не часы. Также можно попробовать в настройках группы Ожидающие включить пункт "Скрыть эту группу из списка пользователей?", в этом случае пользователи, не окончившие процедуру регистрации, не будут видны другим.

Блин, что-то такое мне попадалось, не помню что было...Что указано в настройках: Настройки - Глобальные настройки - Путь до директории загрузок? Именна та папка, которую вы и проверяете? И всё-таки надо бы логи сайта посмотреть.

А в в логах вебсайта есть что-нибудь по проблеме? Вложенные в сообщения картинки загружаются на сервер и отображаются нормально?

Проверьте есть ли папка profile внутри uploads

У меня в указанном параметре стоит 128 МБ, правда я не пользуюсь IP.Downloads. Мне проще - у меня свой сервер, могу рулить там как хочу. Боюсь, что вы не сможете оптимизировать скрипты, как вам советует ТП хостинга. Их я тоже могу понять, с такими запросами от скриптов никакой памяти не напасёшься ) Думаю, что если хостинг не может увеличить этот лимит ещё, то надо менять либо тариф, либо хостинг, но сначала нужно уточнить какие там будут ограничения.

Автоподписка не включена. А вот пинг-серверы были, по-умолчанию, удалил, потестирую. Хотя странно как они могли влиять на приведённый запрос в базу.Спасибо.

Похоже на то, что php-интерпретатору не хватает выделенной ему памяти. Обратитесь к поддержке вашего хостинга с просьбой увеличить память для PHP. Это параметр memory_limit в файле php.ini.

Хоть мы и отошли от темы топика, но всё же хочу уточнить, что ErrorDocument - фича не мод_реврайта или другого модуля, а непосредственно ядра Апача, как сказано в документации.Думаю, дальнейшее осуждение уже не имеет смысла без дополнительной информации от топикстартера.

Жаль. Но надо попробовать. Да толку нет, т.к. в продакшине сайт работает опять на старой версии. А сайт с новой версией стоит без нагрузки, а без нагрузки работает вполне сносно, хотя запрос и на пустом сервере отрабатывает не меньше 20-ти секунд.

162 пользователя онлайн, у меня сейчас 4923 )На их форум я уже писал, ничего интересного не посоветовали. 6947 онлайн. Вот это уже подходит. Спасибо. Отпишу им. Спасибо за предложение, но, думаю, пока не нужно. Напишу сначала админам форума танков )

Боюсь это можно сменить только напрямую в базе данных, если нет такого опыта, то лучше не лезть. А причём тут айпишник, с которого регистрировался пользователь, и айпишники, с которых обращаются на форум? И как вы контролируете эти хиты и лимиты? По моему опыту обычно проблемы из-за гостей, а не из-за зарегистрированных пользователей.

Это зависит от настроек Апача, но по-умолчанию, если я не ошибаюсь, использование такой директивы в .htaccess разрешено. Впрочем, всё это гадание, т.к. как реально настроено у конкретного хостера неизвестно. Наверное правильнее сначала поискать в панели управления хостингом, если таковая имеется, либо почитать FAQ у своего хостера, либо обратиться в поддержку.

Сервер БД - MySQL 5.5.31. Таблица и так в utf8. Пробовал сделать её дамп, удалить и залить снова. Заметных улучшений нет. Подозреваю, что дело в самом запросе и существенно быстрее он выполняться не будет. Первый раз он выполняется секунд 20, последующие разы мгновенно, понятно, что кеш срабатывает, но после изменения таблицы кеш уже устаревает, а таблица у меня меняется постоянно, думаю даже каждую секунду. Другой вопрос, есть ли знакомые форумы с очень большим числом посетителей? Может я бы связался с их админами, поспрашивал.

По идее он называется .htaccess (с точкой вначале). А перенаправить 404-ю ошибку можно примерно вот так: ErrorDocument 404 __www.domain.tld/error404.html

Во-первых, конвертирование личных сообщений заняло почти двое суток, но к этому я был уже готов, т.к. тестировал обновление. После завершения обновления, я потестировал форум сам - всё работало достаточно шустро, но как только я пускал туда пользователей сайт почти сразу впадал в ступор - забивалась очередь в MySQL, веб-сервер запускал максимальное количество процессов и на этом всё заканчивалось. По моим наблюдениям главным виновником был вот этот запрос: SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 Вот кусок от вывода show processlist; | 1703 | d7 | localhost | d7 | Query | 915 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2059 | d7 | localhost | d7 | Query | 915 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2261 | d7 | localhost | d7 | Query | 913 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2313 | d7 | localhost | d7 | Query | 911 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2590 | d7 | localhost | d7 | Query | 905 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2679 | d7 | localhost | d7 | Query | 901 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2782 | d7 | localhost | d7 | Query | 898 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2854 | d7 | localhost | d7 | Query | 895 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2868 | d7 | localhost | d7 | Query | 894 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 2929 | d7 | localhost | d7 | Query | 892 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 3002 | d7 | localhost | d7 | Query | 890 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | | 3009 | d7 | localhost | d7 | Query | 890 | Sending data | SELECT SUM(posts) as replies FROM ibf_topics WHERE approved=1 | И далее ещё куча таких же, а потом уже и других запросов с небольшим временем выполнения. По словам техподдержки Инвижна запрос выполняется при размещении постов. У меня он выполняется секунд 20 на "пустом" сервере, без посетителей. Таблица ibf_topics имеет 11 786 607 строк. А сообщений размещается туча - за сутки 50 тысяч новых тем и 60 тысяч новых постов, это в среднем 34 темы и 41 пост в минуту. Форум большой, много пользователей, но уверен, что есть и ещё большие форумы и при этом нормально работающие. Сервер у меня выделенный и неплохой - HP ProLiant DL380 G7, (2) Intel Xeon X5650, RAM 24GB, ну и RAID-массив из SAS-дисков. Старая версия IPB работает быстро. Не сталкивался ли кто с подобной проблемой? Спасибо.