LINUX.ORG.RU

Apache 2.0.46


0

0

Вышла новая версия Apache - Apache 2.0.46. Эта версия Apache является секьюрити и багфикс релизом.

Changes with Apache 2.0.46

*) SECURITY [CAN-2003-0245]: Fixed a bug that could be triggered remotely through mod_dav and possibly other mechanisms, causing an Apache child process to crash. The crash was first reported by David Endler <DEndler@iDefense.com> and was researched and fixed by Joe Orton <jorton@redhat.com>. Details will be released on 30 May 2003.

*) SECURITY [CAN-2003-0189]: Fixed a denial-of-service vulnerability affecting basic authentication on Unix platforms related to thread-safety in apr_password_validate(). The problem was reported by John Hughes <john.hughes@entegrity.com>.

[...]

Полный changelog: http://www.apache.org/dist/httpd/CHAN...

>>> Подробности

anonymous

Проверено: green

Вопрос к админам:
кто уже пользуется 2.0.x а кто еще 1.3.x?
Имеется в виду не в локалке, разумеется.
И стоит ли уже переходить?

roller ★★★
()

Почти пол года как перешел на Apache 2.0 Использую его на трех серверах более чем пол года. У одного из них входящий трафик одними запросами более полутора гигабайт в сутки. За все время работы ни одного сбоя. Все сервера на FreeBSD. Причины по которым стоит переходить: Он уже достаточно стабилен, проверено временем под нагрузкой. Он работает быстрее, проверено. IMHO Чем быстрее перейдем, тем меньше сил разработчики будут тратить на 1.3 , а следовательно быстрее будет развиваться 2.0 Все равно придется переходить. :)

Best regards, Vitaliy

anonymous
()

А как там с mod_perl и прочими модулями?

ttyS0
()

давно всё нормально

anonymous
()

linux.org.ru работает на apache2 и непосредственно к апачу никаких замечаний нет ;) по крайней мере у меня.

green ★★★★★
()

Поработал месяц на втором апаче и вернулся назад на первый, все таки второй еще сыроват местами, менее надежная штука, плохо себя ведет под большими нагрузками ( входящий траффик на запросы - 700Кбит в секунду, и уже слишком много ест сам апач.. и меньше работает).

anonymous
()
Ответ на: комментарий от green

теперь мне стало ясно почему LOR так глючит и тормозит :-)

anonymous
()
Ответ на: комментарий от green


> и непосредственно к апачу никаких замечаний нет

green, тогда ответь нам, почему так сурово тормозит linux.org.ru? Когда-то грешили на freebsd. Теперь стоит на линуксе. Результат не на много лучше. То есть влияние операционки исключается. Остается apache, postgres, java.
Неужели не интересно довести до конца расследование?
Кто является самым слабым звеном? ;)

anonymous
()


Кстати, апач сам по себе может и нормально работает, но
если он отжирает всю память, то это каюк для остальных приложений.

anonymous
()
Ответ на: комментарий от anonymous

Самый главный текущий bottleneck - postgres, который жрет непомерно cpu на сложных запросах. (ну типа несколько секунд на некоторых запросах, запросто). Я сегодня кое-что в запросах поковырял, еще вчера в сырцах поковырял... Мож полегчает.

Но сдается мне многие уже забыли как оно было на freebsd, а было все намного хуже чем сейчас.

green ★★★★★
()
Ответ на: комментарий от green

Надо же, тут в соседнем треде все уверяют, что постгрес не тормоз ;) А можно увидеть пример сложного запроса? А то как-то не верится, что в таком наколенном поделии, как форум LOR могут быть сложные запросы.

anonymous
()

Из исходников кто-то пробовал ставить 46-й (или 45-й)? С 45-м у меня были проблемы, но как-то прорвался, а с 46-м пока не получается. Хотя, есть предположение, что include-файлы не оттуда тянет.

Что до впечатлений (субъективно), то 45-й, кажется, подторамаживает в сравнении с 27-мым.

popov@kosmos.mk.ua

anonymous
()

Из исходников кто-то пробовал ставить 46-й (или 45-й)? С 45-м у меня были проблемы, но как-то прорвался, а с 46-м пока не получается. Хотя, есть предположение, что include-файлы не оттуда тянет.

Что до впечатлений (субъективно), то 45-й, кажется, подторамаживает в сравнении с 27-мым.

popov@kosmos.mk.ua

anonymous
()
Ответ на: комментарий от anonymous

Пример: SELECT sections.name as ptitle, groups.title as gtitle, topics.title, topics.id as msgid, del_info.reason, comments.postdate FROM sections, groups, topics, comments, del_info WHERE sections.id=groups.section AND groups.id=topics.groupid AND comments.topic=topics.id AND del_info.msgid=comments.id AND comments.userid=? AND del_info.delby!=comments.userid ORDER BY del_info.msgid DESC LIMIT 20;

green ★★★★★
()

2 green: А сколько занимает база у которой msgid=321573

Я примерно полгода назад тоже это проходил. Все тормоза были из-за DESC LIMIT 20. Запрос был практически идентичный. Правда на MySQL, а не на Postgres.

anonymous
()

Продолжение - можно заметить, что если убрать DESC, то скорость увеличивается на 2 порядка. Правда и результат тоже отличается :)

anonymous
()
Ответ на: комментарий от anonymous

Занимает чего?
$ du -ks /var/lib/pgsql/data
256053 /var/lib/pgsql/data

green ★★★★★
()

2 green: А можно про всю архитектуру и если можно с комментариями по чему что было выбрано услышать. какое железо? Как я понял OS - Linux, если не секрет, какой дистрибутив? Почему в качестве BD выбран был postgres? какую JVM используете? какие WEB сервера? (apache jk2 tomcat или что-то другое?)

anonymous
()
Ответ на: комментарий от anonymous

Про архитектуру я ничего незнаю ;) Про железо и софт написано по ссылке "о сервере" на главной странице (шоб поглядеть на железо надо пойти "статистика сервера". Почему был выбьран постгрес я незнаю, н омогу подозревать, чот потому что он много всего умеет :)

Еще раз подчеркиваю что jvm никакого влияния не оказывает совершенно и 90+% времени расходуется постгресом.

green ★★★★★
()

Ну так еще бы она в два раза при наличии desc не уменьшалась :-) Для запросов при наличии order by отдавать данные можно только после заверщения полной выборки и сортировки, а если order by нет, то отдавать можно еще до завершения выполнения запроса - так что "в два раза" - это еще повезло :-) Правда, многое зависит от политики оптимизатора запросов и индексов.

no-dashi ★★★★★
()

А структура БД очень даже ничего, надо признать... Увиденная в запросе схема таблиц позволяет пока что сделать вывод о третьей нормальной форме, хотя бы в приведенном наборе таблиц :-)

no-dashi ★★★★★
()

Не отрывайтесь от темы

Народ вы немного переключились с Апача на Постгрес Если не сложно скажите работает ли в этом апаче поддержка расширения PHP bcmath.so?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.