FreeBSD 4+ Гб ОЗУ
FreeBSD 4+ Гб ОЗУ
На севраке(FreeBSD 6.2 RELEASE) с ядром UTM 5.2.1-004(что то кстати подозрительно много помяти кушать стало) установил ( теперь камень Pentium i386) и 8 Гб ОЗУ... ну резонно фряха сказала типа твой 3+ Гб ОЗУ и гутбай. Вопрос как заставть фряху видеть весь объем памяти? options PAE ?
Почитал тут... http://freebie.miraclenet.co.th/server/install_fbsd/ почитал тут
http://www.ru.freebsd.org/doc/en_US.ISO ... onfig.html
и тутhttp://www.opennet.ru/openforum/vsluhfo ... 493.html#1 и вообще много где... готового и тупого отвента нет (аля options траляля # нужна чтобы...) вобщем в 2-х словах кто уже делал какие опции ядра дял платформы i386 надо врубить в ядро чтобы увиделся весь объем оперативки.
Почитал тут... http://freebie.miraclenet.co.th/server/install_fbsd/ почитал тут
http://www.ru.freebsd.org/doc/en_US.ISO ... onfig.html
и тутhttp://www.opennet.ru/openforum/vsluhfo ... 493.html#1 и вообще много где... готового и тупого отвента нет (аля options траляля # нужна чтобы...) вобщем в 2-х словах кто уже делал какие опции ядра дял платформы i386 надо врубить в ядро чтобы увиделся весь объем оперативки.
Re: FreeBSD 4+ Гб ОЗУ
PAE мы так и не смогли толком запустить на фре в 32 режиме (запускается но работает не так как надо), а на 64 битной фре биллинг не работает , поэтому поставили федору 6 (теперь уже на 16 гиговой машинке с 8 процами мускул занимает 8-12 гиг оперативки а утмка так как 32 битная 4гига но ей больше и не получитсяhammer писал(а):На севраке(FreeBSD 6.2 RELEASE) с ядром UTM 5.2.1-004(что то кстати подозрительно много помяти кушать стало) установил ( теперь камень Pentium i386) и 8 Гб ОЗУ... ну резонно фряха сказала типа твой 3+ Гб ОЗУ и гутбай. Вопрос как заставть фряху видеть весь объем памяти? options PAE ?
Почитал тут... http://freebie.miraclenet.co.th/server/install_fbsd/ почитал тут
http://www.ru.freebsd.org/doc/en_US.ISO ... onfig.html
и тутhttp://www.opennet.ru/openforum/vsluhfo ... 493.html#1 и вообще много где... готового и тупого отвента нет (аля options траляля # нужна чтобы...) вобщем в 2-х словах кто уже делал какие опции ядра дял платформы i386 надо врубить в ядро чтобы увиделся весь объем оперативки.
Re: FreeBSD 4+ Гб ОЗУ
Млин... сетевухи rl и re перестали работать... другие непробовал, но вот http://www.bsdportal.ru/viewtopic.php?t=16544 ситуацию 1 в 1 получил.. е мае... так что ж теперь линукс ставить что ли??? млин чё ж делать(но в линуксе свои прелести с PAE - он там просто по дефолту апосля 2.6.18(?) включен)... Господа разработчики а вот что делать теперь с биллингом когда объемы базы ещё больше увеличатся? Может стоит бинарничек то сделать на 64 битную платформу? Вобщем при наших нагрузках на биллинг проблема актуальна...Magnum72 писал(а):PAE мы так и не смогли толком запустить на фре в 32 режиме (запускается но работает не так как надо), а на 64 битной фре биллинг не работает , поэтому поставили федору 6 (теперь уже на 16 гиговой машинке с 8 процами мускул занимает 8-12 гиг оперативки а утмка так как 32 битная 4гига но ей больше и не получитсяhammer писал(а):На севраке(FreeBSD 6.2 RELEASE) с ядром UTM 5.2.1-004(что то кстати подозрительно много помяти кушать стало) установил ( теперь камень Pentium i386) и 8 Гб ОЗУ... ну резонно фряха сказала типа твой 3+ Гб ОЗУ и гутбай. Вопрос как заставть фряху видеть весь объем памяти? options PAE ?
Почитал тут... http://freebie.miraclenet.co.th/server/install_fbsd/ почитал тут
http://www.ru.freebsd.org/doc/en_US.ISO ... onfig.html
и тутhttp://www.opennet.ru/openforum/vsluhfo ... 493.html#1 и вообще много где... готового и тупого отвента нет (аля options траляля # нужна чтобы...) вобщем в 2-х словах кто уже делал какие опции ядра дял платформы i386 надо врубить в ядро чтобы увиделся весь объем оперативки.
ЗЫ Хотя наверное оптимизации БД и дают ВРЕМЕННЫЕ решения проблеммы, но вот было бы неплхо для начала получить ядро с оптимизированными алгоритмами рабты с памятью на 32 битную платформу.
Последний раз редактировалось hammer Сб фев 16, 2008 01:35, всего редактировалось 2 раза.
При запуске на на боле чем 4G есть много тонкостей.
Что сама сборка 32-битая понятно, но если рассчитывать эффективно использовать память, скажем для запущенного на той же машине SQL, то нужен "правильный" RAID-контроллер который умеет DMA в 64-битном режиме.
На IA32 единственным способом "расширения" области памяти доступной контроллеру это bounce buffer, реализация которого подразумевает копирование блоков памяти. Мы же не зато деньги отдаём чтобы процессор только и занимался тем, что елозил данные по памяти.
AMD64, на сколько мне известно, тоже не предлагает ничего нового в этом плане.
Кстати мне не совсем понятен вопрос с запуском на FreeBSD AMD64. Билинг совершенно точно запускается, правда расширенных тестов не гонял.
Для FreeBSD 7.0 AMD64 Запустить так:
поставить порт /usr/ports/misc/compat6x/
Взять из 32-х битной сборки пакетов libiconv и gettext библиотеки libiconv.so.3 libintl.so.6 и положить на пример в /usr/local/lib32/compat/ . Можно взять libintl.so.8 ( gettext-0.16.1_3), и добавить лишнюю строчку в libmap32.conf.
Сам файлик /etc/libmap32.conf примерно такой:
[/netup/utm5/bin/]
libintl.so.6 libintl.so.8
libpthread.so.2 libthr.so.2
Для 5.2.1-005 наверное понадобятся ещё библиотеки из 32-х битного пакета openssl 0.9.8
Проверяем /netup/utm5/bin/utm5_core - должен запустится, а не падать в кору .
P.S.
hammer, а Вы случайно не даёте пользователям трей-клиент(ну или как там его)? Просто там не особо удачная реализация: на каждого клиента заводится по потоку, хотя сами потоки большую часть времени простаивают, но память при этом все равно используется.
Что сама сборка 32-битая понятно, но если рассчитывать эффективно использовать память, скажем для запущенного на той же машине SQL, то нужен "правильный" RAID-контроллер который умеет DMA в 64-битном режиме.
На IA32 единственным способом "расширения" области памяти доступной контроллеру это bounce buffer, реализация которого подразумевает копирование блоков памяти. Мы же не зато деньги отдаём чтобы процессор только и занимался тем, что елозил данные по памяти.
AMD64, на сколько мне известно, тоже не предлагает ничего нового в этом плане.
Кстати мне не совсем понятен вопрос с запуском на FreeBSD AMD64. Билинг совершенно точно запускается, правда расширенных тестов не гонял.
Для FreeBSD 7.0 AMD64 Запустить так:
поставить порт /usr/ports/misc/compat6x/
Взять из 32-х битной сборки пакетов libiconv и gettext библиотеки libiconv.so.3 libintl.so.6 и положить на пример в /usr/local/lib32/compat/ . Можно взять libintl.so.8 ( gettext-0.16.1_3), и добавить лишнюю строчку в libmap32.conf.
Сам файлик /etc/libmap32.conf примерно такой:
[/netup/utm5/bin/]
libintl.so.6 libintl.so.8
libpthread.so.2 libthr.so.2
Для 5.2.1-005 наверное понадобятся ещё библиотеки из 32-х битного пакета openssl 0.9.8
Проверяем /netup/utm5/bin/utm5_core - должен запустится, а не падать в кору .
P.S.
hammer, а Вы случайно не даёте пользователям трей-клиент(ну или как там его)? Просто там не особо удачная реализация: на каждого клиента заводится по потоку, хотя сами потоки большую часть времени простаивают, но память при этом все равно используется.
Кастыль... уже тут помоему пару тем было AMD64 и UTM... все заканчивались выводом - "зачем этот гемор"?Arti писал(а): ...Взять из 32-х битной сборки пакетов libiconv и gettext библиотеки...
И в мыслях небыло это чудо использовать - порт тупо закрыт фаерволом а абонеты даже не в курсе что такая утилита сущесвует - я уже несколько раз писал об этом на форуме. Все приучены в веб лазить - не слишком удобно, но зато проблемм меньше.Arti писал(а): hammer, а Вы случайно не даёте пользователям трей-клиент(ну или как там его)?
Немного не понял. В чём костыль то? Прога 32-х битная часть библиотек линкуется динамически:hammer писал(а):Кастыль... уже тут помоему пару тем было AMD64 и UTM... все заканчивались выводом - "зачем этот гемор"?Arti писал(а): ...Взять из 32-х битной сборки пакетов libiconv и gettext библиотеки...
Код: Выделить всё
tbil# ldd /netup/utm5/bin/utm5_core
/netup/utm5/bin/utm5_core:
libssl.so.4 => /usr/lib/libssl.so.4 (0x28416000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0x28448000)
libcrypt.so.3 => /lib/libcrypt.so.3 (0x28552000)
libz.so.3 => /lib/libz.so.3 (0x2856b000)
libintl.so.6 => /usr/X11R6/lib/libintl.so.8 (0x2857c000)
libiconv.so.3 => /usr/X11R6/lib/libiconv.so.3 (0x2858e000)
libpthread.so.2 => /lib/libpthread.so.2 (0x2867c000)
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x286a3000)
libm.so.4 => /lib/libm.so.4 (0x28778000)
libc.so.6 => /lib/libc.so.6 (0x2878e000)
На самом деле костыль - это сама попытка запуска на боле 4Gb - польза для самого билинга около нулевая.
Если требуется действительно увеличить производительность, то прежде всего надо разнести билинг с SQL по разным машинам ну и может быть ещё отселить radius.
На счёт трей клиента я с Вами полностью солидарен - от него одни проблемы. Его неиспользование - просто ещё одна возможность освободить немного памяти.
1 - почему костыль - поиск по форуму.
2 - MySQL и так на одельной тачке с 2 Opteron ами на борту и 8 Гб ОЗУ - используется как центральный сервак БД (по производительности там вопросв нет). Просто не только база биллинга там вертится - а вот когда отчет за парму месяцев надо сотавить по пользователям (за отрезок времени, когда база не оптимизирована), да ещё и вечерком, когда народ в Инете активно лазает - тогда у ядра в пике загрузка помяти больше 1 Гб сразу и радиус не далеко от него маячит - а вот очищать сразу память, после завершения задачи (покрайней мере ядро) они не спешат... Я так прикинул - в пике на процессы ядра и радиуса может быть до 4 Гб ОЗУ.
Ну я вообще я согласен - да ядро и радиус при таких нагрузках лучше держать на разных машинах, как вариант сервак с 3 Гб ОЗУ ТОЛЬКО на ядро (2 на ядро и 1 на "всякий случай").
Вобщем щас без PAE на 3,5 Гб ОЗУ пока бегает все, надо будет уберу радиус. А вот дальше видно будет...
ЗЫ в дургом топике про UTM и FreeBSD было сказано что ядро на i386 не собирается с MAXSDIZ="(2*1024*1024*1024)" - это верно (ошибка что то вроде overload integer или типа того) - а вот с MAXSDIZ="(2048ULL*1024*1024)" собирается.
2 - MySQL и так на одельной тачке с 2 Opteron ами на борту и 8 Гб ОЗУ - используется как центральный сервак БД (по производительности там вопросв нет). Просто не только база биллинга там вертится - а вот когда отчет за парму месяцев надо сотавить по пользователям (за отрезок времени, когда база не оптимизирована), да ещё и вечерком, когда народ в Инете активно лазает - тогда у ядра в пике загрузка помяти больше 1 Гб сразу и радиус не далеко от него маячит - а вот очищать сразу память, после завершения задачи (покрайней мере ядро) они не спешат... Я так прикинул - в пике на процессы ядра и радиуса может быть до 4 Гб ОЗУ.
Ну я вообще я согласен - да ядро и радиус при таких нагрузках лучше держать на разных машинах, как вариант сервак с 3 Гб ОЗУ ТОЛЬКО на ядро (2 на ядро и 1 на "всякий случай").
Вобщем щас без PAE на 3,5 Гб ОЗУ пока бегает все, надо будет уберу радиус. А вот дальше видно будет...
ЗЫ в дургом топике про UTM и FreeBSD было сказано что ядро на i386 не собирается с MAXSDIZ="(2*1024*1024*1024)" - это верно (ошибка что то вроде overload integer или типа того) - а вот с MAXSDIZ="(2048ULL*1024*1024)" собирается.
Ещё раз настоятельно рекомендую отделить мух от котлет. Сама попытка запуска - да костыль.hammer писал(а):1 - почему костыль - поиск по форуму.
Удовлетворение зависимостей - костылём быть не может. Мы же не называем костылём, то что скажем gmplayer использует GTK2 для GUI и соответственно тащит его как зависимость и в последствии libgtk-x11-2.0.so.0 динамически линькуется при запуске.
Просто делать кросплатформенный билд ради пары библиотек - глупое занятие, кроме того я ничего не знаю об механизме ситемы портов, позволяющего "правильно" устанавливать пакеты собранные под IA32 в систему AMD64.
P.S.
2*1024*1024*1024 = 2^31 т.е. знаковый бит для 32 битного целого.
-
- Сообщения: 116
- Зарегистрирован: Вт май 15, 2007 12:50
Можно рабочий конфиг либмапа и что нужно сделать? Что то вообще ничего не получается
FreeBSD 6.3-STABLE #0 amd64
Utm-5.2.1.004
FreeBSD 6.3-STABLE #0 amd64
Utm-5.2.1.004
Последний раз редактировалось Mental Noize Чт июл 17, 2008 12:28, всего редактировалось 1 раз.