Покажи Публикации - gat3way
* Виж публикациите на потр. | Виж темите на потр. | Виж прикачените файлове на потр
Страници: 1 ... 407 408 [409]
6121  Linux секция за начинаещи / Настройка на програми / добавяне на рутинг -: Sep 12, 2006, 12:33
Некой трябва да си прочете OSI модела...бъркаш мрежовия и транспортния слой. Апропо, това което вероятно целиш се прави с DNAT.
6122  Програмиране / Общ форум / Работа с големи буфери в ядрото -: Sep 12, 2006, 12:02
Тъй...регистрирах се, блях

Ъм...при мен изхода от програмата е:

ret:1048576
ret:1048576
.....
......
ret:1048576
ret:-1
Memory Read:896 MB

896МВ е големината на ZONE_NORMAL, /dev/mem не дава достъп до ZONE_HIMEM, така че няма как да изчета останалата памет до 1280-тия мегабайт.

Т.е при мен няма проблем с изчитането.

Сега обаче като се замисля...вероятно причината за това е хардуерен. Доколкото знам първите 16MB се водят ZONE_DMA - т.е адресно пространство използвано за ДМА трансфери от ISA и някои PCI устройства..нямам обаче много ясна идея защо става така при теб.

Можеш ли да пейстнеш какво има в /proc/zoneinfo BTW?
6123  Linux секция за напреднали / Хардуерни и софтуерни проблеми / Dns въпрос -: Sep 11, 2006, 10:24
Не мисля, че това което правиш е разумно..
Имаш ТТЛ за зоната доста голямо време...което ще рече че толкова време един клиент, който е резолв-нал вече хост-а, ще си го пази в днс кеша и няма да ти допитва днс сървъра.

Което означава, че такъв клиент при падане на едната ти линия все пак ще търси хоста на стария адрес, който вече е кеширан при него. И като не го намери, няма да се свърже с него.

Като изход от тази ситуация, предлагам следното: много нисък ТТЛ. 2 authoritative сървъра - съответно на двете айпита на двата интерфейса. 2 instances на bind, слухтящи съответно на единия и другия интерфейс, със съответните зонови файлове съобразени с адресите на интерфейсите им.

Като резултат, при падане на единия интерфейс, проблемите ще бъдат сведени до минимум...с едно огромно "НО":

Предполагам имаш apache. Ако имаш vhosts, би следвало да знаеш, че няма да сработят автоматично при падане на единия интерфейс. Апача прави един път резолвинг на всеки виртуален хост в конфигурацията си по време на стартиране и повече не се грижи за това. Тоест, ако по време на работа адреса на един виртуален хост (A record-a) бъде сменен, то апач-а няма да знае за това, съответно ще си имаш грижи. За това, трябва да се напише и един скрипт, който се изпълнява всяка минута в крон-а и проверява дали не е паднал интерфейс-а. Ако е паднал, тогава се прави един reload на апач-а, за да си нямаш грижи с виртуалните хостове.

За други "уточнения" не мога да се сетя в момента..
Страници: 1 ... 407 408 [409]