Есть ли в планах сборка под AMD64?
Есть ли в планах сборка под AMD64?
Есть ли в планах сборка под AMD64?
Не совсем понял что значит за отдельную оплату с тестированием? Я так понимаю, что отличается фактически только параметрами компиляции или туда входят какие то глобальные изменения отличающиеся от стандартной?
PS: Вопрос возник из-за предстоящего апгрейда. Нам надо будет дополнительно оплачивать сборку под оптероны?
PS: Вопрос возник из-за предстоящего апгрейда. Нам надо будет дополнительно оплачивать сборку под оптероны?
Как показывает практика при сборке под 64 битные платформы будет куча "заморочек" с типами данных (в частности при передаче по сети и т.д.) и соответсвенно это нужно а) исправлять б) тестировать в) сопровождать если появятся проблемы.Nick писал(а):Не совсем понял что значит за отдельную оплату с тестированием? Я так понимаю, что отличается фактически только параметрами компиляции или туда входят какие то глобальные изменения отличающиеся от стандартной?
PS: Вопрос возник из-за предстоящего апгрейда. Нам надо будет дополнительно оплачивать сборку под оптероны?
На данный момент если вам необходима такая сборка, то мы можем ее провести, но как я уже писал выше за отдельную оплату - либо подождите когда данная платформа будет действительно востребована и мы сделаем билд на общих основаниях ...
2All: Нетап объявил сумму за сборку сопоставимую со стоимостью биллинга. Если нетап разрешит то оглашу, или сами напишут сколько.
Кроме меня это кому то надо? Если надо то может быть объеденим усилия, напишем коллективное письмо о том что это надо, и коллективно оплатим счет? %)
2Netup: Все равно к этому через пол-годика придем. На всех более-менее приличных серверах будет AMD64 (EM64T).
Кроме меня это кому то надо? Если надо то может быть объеденим усилия, напишем коллективное письмо о том что это надо, и коллективно оплатим счет? %)
2Netup: Все равно к этому через пол-годика придем. На всех более-менее приличных серверах будет AMD64 (EM64T).
Сумму озвучить конечно можно - это не секрет. Насчет портирования, повторюсь, это пока неприоритетная задача. Плюс это работа, которая должна быть оплачена. Да и загрузка сейчас большая по частным доработкам - придется переключать людей на эту задачу ...Nick писал(а):2All: Нетап объявил сумму за сборку сопоставимую со стоимостью биллинга. Если нетап разрешит то оглашу, или сами напишут сколько.
Кроме меня это кому то надо? Если надо то может быть объеденим усилия, напишем коллективное письмо о том что это надо, и коллективно оплатим счет? %)
2Netup: Все равно к этому через пол-годика придем. На всех более-менее приличных серверах будет AMD64 (EM64T).
Для нас пока (!) эта задача выглядит больше тратой времени нежели реально нужной. По оценкам скорость вырастет незначительно. Гораздо больше прибавки можно получить за счет:
1. Улучшения дисковой подсистемы. Поставьте скази 320 и винчестеры атлас 15к. Какой контроллер и диски у вас сейчас ?
2. Увеличения и ускорения памяти. Установите двухканальный ддр 3200 и 32битный процессор с 800й шиной.
3. Есть еще вариант ускорения "внутри" самого ядра и оптимизация работы с базой данных. Думаю этот пункт даст самый существенный прирост. Сейчас как раз проводятся такие работы - результаты пока очень обнадеживающиие.
Это наши соображения. Как говорится можем ошибаться, но тогда желательно аргументированно показать где ...
В любом случае с удовольствием выполним портирование под 64битную архитектуру если вы согласитесь на доработку.
само собой. В одном из ближайших билдов будет много изменений в этом плане ...cjcrazy писал(а):будут ли оглашены результаты работы?aospan писал(а): 3. Есть еще вариант ускорения "внутри" самого ядра и оптимизация работы с базой данных. Думаю этот пункт даст самый существенный прирост. Сейчас как раз проводятся такие работы - результаты пока очень обнадеживающиие.
Доработка была оценена в 700 у.е.Сумму озвучить конечно можно - это не секрет. Насчет портирования, повторюсь, это пока неприоритетная задача. Плюс это работа, которая должна быть оплачена. Да и загрузка сейчас большая по частным доработкам - придется переключать людей на эту задачу ...
Для нас пока (!) эта задача выглядит больше тратой времени нежели реально нужной. По оценкам скорость вырастет незначительно.
В принципе никто никуда не торопится, можно и подождать все равно через какое то время сделаете, наверное
Или, если есть заинтересованные то можно сложится и, тем самым, уменьшить сумму на каждого, если, конечно, Netup не будет против.
Это понятно, дисковая система, как показыват анализ, часто становится узким местом. Сейчас 10k ultra160. и 4Gb памяти. Ядро и база на одной машине. Просто вопрос возник в свете покупки нового сервера под биллинг, который уже будет поддерживать 64-х битную архитектуру. Правда пока еще думается мысль как сделать лучше - разнести ядро на одну машину, а sql базу на другую соеденив их скажем, гигабитом или двумя, или оставить все на одной. Сердцем чуствую, что первый варинт получится более производительный. Может посоветуете?Гораздо больше прибавки можно получить за счет:
1. Улучшения дисковой подсистемы. Поставьте скази 320 и винчестеры атлас 15к. Какой контроллер и диски у вас сейчас ?
2. Увеличения и ускорения памяти. Установите двухканальный ддр 3200 и 32битный процессор с 800й шиной.
А можно узнать поподробнее? И в каких релизах результаты будут доступны нам?3. Есть еще вариант ускорения "внутри" самого ядра и оптимизация работы с базой данных. Думаю этот пункт даст самый существенный прирост. Сейчас как раз проводятся такие работы - результаты пока очень обнадеживающиие.
Nick писал(а):Мы абсолютно не против ...Доработка была оценена в 700 у.е.
В принципе никто никуда не торопится, можно и подождать все равно через какое то время сделаете, наверное
Или, если есть заинтересованные то можно сложится и, тем самым, уменьшить сумму на каждого, если, конечно, Netup не будет против.
скази 160 конечно медленновато ... сейчас посмотрел - линейная скорость чтения/записи не выше 35 МБ/сек, что даже хуже обычных ATA100/SATA, у которых 55-60 МБ/сек.Это понятно, дисковая система, как показыват анализ, часто становится узким местом. Сейчас 10k ultra160. и 4Gb памяти.
Согласен, что скази "более интеллектуальный" и меньше грузит CPU, но всё же ...
выносить в принципе дейстивтельно можно если естьдве хорошие машины, но тут возникает вопрос с поддержкой - проще сопрвождать одну машину нежели две. По приросту не скажу т.к. к сожалению данных нет. Но многие такую схему используют - нареканий вроде нет.Ядро и база на одной машине. Просто вопрос возник в свете покупки нового сервера под биллинг, который уже будет поддерживать 64-х битную архитектуру. Правда пока еще думается мысль как сделать лучше - разнести ядро на одну машину, а sql базу на другую соеденив их скажем, гигабитом или двумя, или оставить все на одной. Сердцем чуствую, что первый варинт получится более производительный. Может посоветуете?
В частности будет переделан механизм тарификации нетфлоу (ускорен во много раз за счет более оптимизированного алгоритма) и плюс запись нетфлоу можно будет вести в сырые файлы не используя гигабейз т.е. это будут обычные бинарные файлы нашего внутреннего формата (на самом деле туда будет литься просто чистый нетфлоу). Пока один недостаток этого метода хранения - нет выборки детальки из админки и веба - есть специальная консольная утилита. Плюсы есть - значительное ускорение записи плюс меньше занимает места на диске (примерно на 20-30 % больше чем пришедший по сети нетфлоу) и т.д.А можно узнать поподробнее? И в каких релизах результаты будут доступны нам?
-
Wishmaster
- Сообщения: 309
- Зарегистрирован: Сб апр 16, 2005 11:44
Я, похоже, понял, почему нет особого желания ее делать. На AMD64 в сишной библиотеке time_t имеет размер 64 бита, а не 32. Соответственно счетчик юниксового времени будет 64-битный в коде, а в базе 32-битный. Это первое. Второе - все 32-разрядные значения должны явно маскироваться с 0x0FFFFFFFF для обеспечения беззнаковой 64-битной арифметики. А теперь можно себе представить, сколько таких точек есть в коде UTM 5. Легче с нуля все написать.