???
Ето ж бета-алфа.
Релиз - 4.0
http://www.mysql.com/downloads/index.html
Я к сожалению не помню и списка не вел. По моему, техинфо, еще чегото. можно компилить. Как ругатся будет - даунлодить.
Пейнфулл процесс.
Siberian Cableman wrote:Кстати, Вы выяснили насчёт памяти от Ultra 60?
Каскыр, я конечно сильно извиняюсь, но пока сумел найти только, 256 (4 чипа по 64) Мег памяти. Вполне возможно, что остатки я унес на работу.
Характеристики:
Manufacturing Part # 501-2480 [F]
Option # X7003A 7 [S]
64MB 5V ECC
60ns DIMM
Линк на эту память и подтверждение, что она поддерживаеться Sun Ultra 2:
http://sunsolve.sun.com/handbook_pub/De ... 7003A.html
Каскыр, напиши какой хоть процессор-то?
В компьютеры Sun Ultra 2 устанавливаются 64 разрядные процессоры Ultra SPARC. Тот процессор, что у Вас, не подойдёт: он 32 разрядный Super SPARC, AKA Viking.
Это безусловно ценная информация , но мой воппос был приземленнее. Перефразирюю: какая модел процессора, что Вы уже имеете в Ultra 2?
Siberian Cableman wrote:Так она еще и SBUS !!!!!, я только теперь сообразил зачем про SBUS спаршивали.
Линк на информацию по U-2:
http://www.sunstuff.org/hardware/system ... 4u/ULTRA2/
Короче, я все равно не знал, что делать со старой SS20, так вот самое оно ее презентовать привету, все что там есть на ура может пойти в зип: видео карта, блок питания (вроде как похож, но надо проверить), cd-rom
Я к сожалению не помню и списка не вел. По моему, техинфо, еще чегото. можно компилить. Как ругатся будет - даунлодить.
Пейнфулл процесс.
vovap wrote:Siberian Cableman wrote:Между прочим кто работает медленнее: база возврашяет запрос, или phpBB генерит страницу? Может от этого и плясать?
База, конено.
Насколько вроде удалось разобраться моей тупости phpBB сам по себе с точки зрения нагрузки вообще не при чем.
Нагрузка определяется базой и реал-тайм сжатием страниц бибиотекой сжатия. (страници- то посылаются в сжатом виде и если вспомнить на каком канале мы сидим, только благодаря этому сайт и держится)
Наибольшая проблемма в базой - система поиска. Для ее обеспечения каждый пост при посте парсится на слова. они проверяются по таблице уникальных лексических элементов, если нет - заносятся туда. И ID слов заносятся в таблицу соответствия слов-постов. Потом на этом работает поиск.
Разумеется, такой механизм рождает колоссальный оверхед при каждм посте.
Теперешняя версия MySql имеет вроде уже полнотекстовый поск по мемо полям. Но так как PhpBB абстрагирована от специфики конкретной базы - она его не использует. Если бы удалось переделать поиск под этот механозм - это. вероятно, дало бы очень значительный выигрыш в общей производительности базы.
Privet wrote:Я не думаю, что сжатие так много занимает процессорного времени. Основные потребители - phpBBи MySQL. Проблема в том, что ISAPI версия php sucks (об этом сразу предупреждается даже в инструкции) и я вынужден пользовать php.exe. Каждый запрос генерит новый процесс. В сумме они потребляют немало.
Сам поиск (select) работает относительно быстро. Большую нагрузку вызывает редактирование. Приходится убирать все ссылки на слова в старом сообщении и вставлять в таблицу ссылку на каждое слово опять.
Таким образом, просто разнос сайта на два сервера должен дать результат.
Privet wrote: Проблема в том, что ISAPI версия php sucks (об этом сразу предупреждается даже в инструкции) и я вынужден пользовать php.exe. Каждый запрос генерит новый процесс. В сумме они потребляют немало.
Сам поиск (select) работает относительно быстро. Большую нагрузку вызывает редактирование. Приходится убирать все ссылки на слова в старом сообщении и вставлять в таблицу ссылку на каждое слово опять.
Таким образом, просто разнос сайта на два сервера должен дать результат.
Privet wrote:Я не думаю, что сжатие так много занимает процессорного времени. Основные потребители - phpBBи MySQL. Проблема в том, что ISAPI версия php sucks (об этом сразу предупреждается даже в инструкции) и я вынужден пользовать php.exe. Каждый запрос генерит новый процесс. В сумме они потребляют немало.
Сам поиск (select) работает относительно быстро. Большую нагрузку вызывает редактирование. Приходится убирать все ссылки на слова в старом сообщении и вставлять в таблицу ссылку на каждое слово опять.
Таким образом, просто разнос сайта на два сервера должен дать результат.
mbabayan wrote:Privet wrote:Я не думаю, что сжатие так много занимает процессорного времени. Основные потребители - phpBBи MySQL. Проблема в том, что ISAPI версия php sucks (об этом сразу предупреждается даже в инструкции) и я вынужден пользовать php.exe. Каждый запрос генерит новый процесс. В сумме они потребляют немало.
Сам поиск (select) работает относительно быстро. Большую нагрузку вызывает редактирование. Приходится убирать все ссылки на слова в старом сообщении и вставлять в таблицу ссылку на каждое слово опять.
Таким образом, просто разнос сайта на два сервера должен дать результат.
А может сменить веб-сервер на Win32 apache, и использовать модуль PHP ? тогда от оверхеда, связнанного с созданием процесса на каждый запрос, можно было бы избавиться.
Privet wrote:Я не думаю, что сжатие так много занимает процессорного времени. Основные потребители - phpBBи MySQL.
mbabayan wrote:А может сменить веб-сервер на Win32 apache, и использовать модуль PHP ? тогда от оверхеда, связнанного с созданием процесса на каждый запрос, можно было бы избавиться.
f_evgeny wrote:mbabayan wrote:А может сменить веб-сервер на Win32 apache, и использовать модуль PHP ? тогда от оверхеда, связнанного с созданием процесса на каждый запрос, можно было бы избавиться.
Я думаю, что если это не апач 2, это не поможет. Так как апач 1.3 все равно на каждого клиента порождает процесс. На Юниксе это нормально, на Win32 нужно то же самое делать на тредах. Вроде Апач 2 так и сделан, хотя я win32 особо не интересуюсь.
mbabayan wrote:Точно уже не помню, но по моему Апач 1.3 на вине делал это тредами.
Апач 2 - точно не порождает новых процессов, недавно его ставил и конфигурил под него РНР, правда для девелопмента, а не продакшн.
f_evgeny wrote:mbabayan wrote:Точно уже не помню, но по моему Апач 1.3 на вине делал это тредами.
Апач 2 - точно не порождает новых процессов, недавно его ставил и конфигурил под него РНР, правда для девелопмента, а не продакшн.
В 1.3 - процессы. Я уверен, а завтра еще и проверю на работе.
Siberian Cableman wrote:Эй, а почему ftp (plain text) открыт? закрыть и использовать только scp
ftp> open 66.127.248.52
Connected to 66.127.248.52.
220 frontend FTP server (SunOS 5. ready.
User (66.127.248.52:(none)):
Siberian Cableman wrote:Там с матерью проблемы. Все регулярно в дамп уходит. Посему и приговор машине: в металлолом. Может кто-нибудь и захочет привести это в чувство. Тогда ради бога.
Поймите пожалуйста Каскыр, что при количестве народу на форуме, все должно работать как продакшен система, т.е. так же надежно.
Посему решение использовать хлам обойдеться ПОТОМ в часы простоя. Между прочим кому-то, кто задает вопросы по работе/иммиграции, это может стоить потери реальных денег. Посему я голосую за нормальное железо. И что-бы не быть голословным, я вместе с железом передам Борису чек на фиревалл для привета. Если найдется еше человек 8 разделяющих мою точку зрения, то вот фиревалл и куплен.
Без обид: Ваши действия по сохранению железа любой ценой, попахивают радио-либительством. Не обижаитесь, я сам такой, лет 5 до института плюс РТФ МЭИ, но тут это будет только на вред.