Срочно: WEB-морда и amd64

[kaN5300]

Мне вот нравится вариант когда на одном тазике база-онли с быстрыми дисками и тонной оперативки, а на другом вебка и ядро с радиусом. Но не окажется ли в этой системе слабым звеном TCP/IP, пусть даже тачки эти метровым патчкордом по гигабиту будут соединены...

[NShut]

to kaN5300

пусть даже при плохом соединении гигабитном, скорость допустим передачи 80метров в секунду. очевидно что скорее винт будет слабым звеном чем сеть (незабываем тормоза fs во фре). ну и за 2 сек в будет передача по 160метров в каждую сторону. по идее такой загрузки можно добиться только синхронизируя всю бдшку. В любом случае скорее ядро УТМ умрет от такого потока чем сеть
ну и плюс ко всему, даже если такое вдруг случиться, что мешает еще пару гигабиток втыкнуть

[alexeyp5]

15:30 pavlov2@apollon [~]#uname -a

FreeBSD яяяяяя.яяяяяя.ru 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Nov 5 15:20:26 MSK 2009 pavlov@яяяя.яяяя.ru:/usr/obj/usr/src/sys/APOLLON amd64
15:30 pavlov2@apollon [~]#ps -ax | grep core
55212 p0- I 0:00.00 /bin/sh /netup/utm5/bin/safe_utm5_core start
55214 p0- S< 16:21.16 /netup/utm5/bin/utm5_core
59670 p0 S+ 0:00.00 grep core

15:30 pavlov2@apollon [~]#cat /etc/libmap32.conf
[/usr/local/www/apache22/cgi-bin/utm5/aaa5]
libiconv.so.3 libiconv.so.03
libxml2.so.5 libxml2.so.05
libxslt.so.2 libxslt.so.02
libxslt.so libxslt.so.02

[/usr/local/www/apache22/cgi-bin/utm5/user5]
libiconv.so.3 libiconv.so.03
libxml2.so.5 libxml2.so.05
libxslt.so.2 libxslt.so.02
libxslt.so libxslt.so.02

Библиотеки стырены с i386

[kaN5300]

to kaN5300

допустим передачи 80метров в секунду. очевидно что скорее винт будет слабым звеном чем сеть

Тем более, если сравнить объемы того, что будет перелопачиваться непосредственно на машинке с базой и объемы того, что будет отдаваться клиенту (ядру). Я думаю, трафик будет минимальный. Интересно, у кого-нибудь построена такая схема? Всё же не хотелось бы выкидывать ставый сервак, а как раз занять его вебкой и демонами нетаповскими. Ну и сырую статистику на него положить.

[Wishmaster]

to kaN5300

допустим передачи 80метров в секунду. очевидно что скорее винт будет слабым звеном чем сеть

Тем более, если сравнить объемы того, что будет перелопачиваться непосредственно на машинке с базой и объемы того, что будет отдаваться клиенту (ядру). Я думаю, трафик будет минимальный. Интересно, у кого-нибудь построена такая схема? Всё же не хотелось бы выкидывать ставый сервак, а как раз занять его вебкой и демонами нетаповскими. Ну и сырую статистику на него положить.

Использую именно такую схему.
1 сервер bsd_i386 - ведро, радиус, веб.
2 сервер bsd_amd64 - база.

Работает без проблем. При такой схеме, как в прочем и при остальных, узким местом остается сам УТМ а точнее - отчетно статистическая часть. Гигабитного линка - выше крыши. Максимальный поток данных, который я там видел, был 40-60 мегабит.

Деталка за последнее время (где-то месяц) лежит на том же серваке, что и ведро, по мере устаревания она архивируется на сервер с архивами. (использую штатную возможность ведра - fd_script.sh) В целом, на мой взгляд, это наиболее приемлемая схема. В прочем, учитывая увеличение нагрузки, планирую перенести радиус на отдельный сервак, а впоследствии, может быть и веб-морду.

Удручает факт нежелания нетапа сделать 64-битную сборку ведра и сервисов, хотя для такого продукта, как биллинг, возможность использовать максимум аппаратных ресурсов - априори, одна из главных возможностей. Но, это уже из другой оперы.

[kaN5300]

Респект! Можно для информации версии бзды и мускуля узнать? А вебку я еще думал для безопасности выкинуть на наш штатный веб-сервер, дабы избавиться от апача и ко.

[Wishmaster]

Респект! Можно для информации версии бзды и мускуля узнать? А вебку я еще думал для безопасности выкинуть на наш штатный веб-сервер, дабы избавиться от апача и ко.

Да, относительно вебки те же мысли посещали, но пока есть другие задачи.

Ведро стоит на 7.0-RELEASE-p2/i386, база - 7.0-RC3/amd64, mysql - 5.1.26.

[dwemer]

у нас всегда были база, ядро и вебка на 3-ёх разных машинах .
сейчас подумываю ядро с базой в 1 машину посадить. ожидаю все же бонусов от локальной передачи данных вместо тсп.

[Wishmaster]

у нас всегда были база, ядро и вебка на 3-ёх разных машинах .
сейчас подумываю ядро с базой в 1 машину посадить. ожидаю все же бонусов от локальной передачи данных вместо тсп.

Вряд ли будет разница в производительности. Как уже неоднократно выяснялось на этом форуме, UTM тормозит, в основном, по причине неоптимизированности запросов, структуры БД и самих данных, так что, скорость обмена между ядром и БД не является узким местом, если она (скорость) не меньше 100 мегабит. При варианте, когда каждый сервис на своей тачке есть дополнительный плюс, если вдруг, ядро по каким либо причинам роняет тачку в kernel panic, а такое бывало, то база при этом не страдает, теряется только то, что было в кеше ядра, а это согласитесь лучше, чем побитый innodb.

Мое мнение не претендует на истину в последней инстанции. Всего лишь жизненное наблюдение. Подобную схему я использую еще со времен UTM3 и проблем никогда не возникало.

Вообще, из области фантастики, было бы круто, если нетап сделал бы синхронизацию кеша из RAM в файл на диске, типа свопа, в реальном режиме времени. В случае неожиданного падения, ядро могло бы считать данные из этого файла и минимизировать таким образом возможные проблемы. В прочем, это уже оффтопик.

[adeep]

FreeBSD 8 amd64

# cat /etc/libmap32.conf
[utm5_urfaclient]
libxml2.so.5 libxml2.so.4
libiconv.so.3 libiconv.so.2

[aaa5]
libxml2.so.5 libxml2.so.4
libiconv.so.3 libiconv.so.2


[user5]
libxml2.so.5 libxml2.so.4
libiconv.so.3 libiconv.so.2

[utm5_core]
libintl.so.8 libintl.so.7
libiconv.so.3 libiconv.so.2

[mikkey finn]

Вообще, из области фантастики, было бы круто, если нетап сделал бы синхронизацию кеша из RAM в файл на диске, типа свопа, в реальном режиме времени. В случае неожиданного падения, ядро могло бы считать данные из этого файла и минимизировать таким образом возможные проблемы. В прочем, это уже оффтопик.

дык вроде есть уже. в 007 оно вроде ведет какой-то файл, по крайней мере для нетфло.

[Wishmaster]

Вообще, из области фантастики, было бы круто, если нетап сделал бы синхронизацию кеша из RAM в файл на диске, типа свопа, в реальном режиме времени. В случае неожиданного падения, ядро могло бы считать данные из этого файла и минимизировать таким образом возможные проблемы. В прочем, это уже оффтопик.

дык вроде есть уже. в 007 оно вроде ведет какой-то файл, по крайней мере для нетфло.

Как я понял, это работает в случае корректного завершения работы ядра. А если оно упало в корку, или иной сбой - нет.

[Vlad83]

15:30 pavlov2@apollon [~]#uname -a

FreeBSD яяяяяя.яяяяяя.ru 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Nov 5 15:20:26 MSK 2009 pavlov@яяяя.яяяя.ru:/usr/obj/usr/src/sys/APOLLON amd64
15:30 pavlov2@apollon [~]#ps -ax | grep core
55212 p0- I 0:00.00 /bin/sh /netup/utm5/bin/safe_utm5_core start
55214 p0- S< 16:21.16 /netup/utm5/bin/utm5_core
59670 p0 S+ 0:00.00 grep core

15:30 pavlov2@apollon [~]#cat /etc/libmap32.conf
[/usr/local/www/apache22/cgi-bin/utm5/aaa5]
libiconv.so.3 libiconv.so.03
libxml2.so.5 libxml2.so.05
libxslt.so.2 libxslt.so.02
libxslt.so libxslt.so.02

[/usr/local/www/apache22/cgi-bin/utm5/user5]
libiconv.so.3 libiconv.so.03
libxml2.so.5 libxml2.so.05
libxslt.so.2 libxslt.so.02
libxslt.so libxslt.so.02

Библиотеки стырены с i386

Сделал как тут описано, просто из консоли aaa5 начал отрабатывать и перестал ругаться ! А если обращаться к нему через www пишет тоже самое /libexec/ld-elf.so.1: /usr/local/lib/libxslt.so.2: unsupported file layout в логи,получается что не видит линки из libmap32.conf,как быть подскажите пожалуйста ?

[alexeyp5]

Возможно поможет стоп старт апача.
И точно убедитесь что библиотеки стащены с i386

http://bez-sms.info/amd64.zip
Тут можно взять рабочие с моей системы.