iHead

iHead
Рейтинг
137
Регистрация
25.04.2008
Интересы
Hosting (PHP, Bitrix), domains
'[umka:
;9602713']Как не надо? Тоже надо, он как и пхп содержит свою базу таймзон.
По-идее, вот этот запрос
SET SESSION time_zone = 'Europe/Moscow';
SELECT FROM_UNIXTIME(1319932800);
на машине с новой таймзоной Europe/Moscow и на машине со старой таймзоной должен выдать разные результаты.

у вас какая версия MySQL?

SELECT NOW()

без всяких SET что показывает?

iHead добавил 30.10.2011 в 17:57

MySQL использует файлы

/usr/share/zoneinfo, которые скорее относятся к ОС.

Если в ОС установлен правильное время, то MySQL ковырять не нужно.

ИМХО :)

'[umka:
;9602674']Ага, видимо, не обновили таймзоны в mysql :)
/ru/forum/comment/9602297
Тоже поленились )
Просто это можно было неспеша сделать ещё полгода назад.

я думаю, что они мускуль непередернули седня. в нем что-то обновлять отдельно не надо. по крайней мере у меня он подхватил системное время после рестарта.

проблема в том, что в первый раз не очевидно, какой софт требует шаманства, какой рестарта, а какой все сам подхватывает.

походу у серча тоже проблемы. в сообщении выше:

iHead добавил 30.10.2011 в 17:12

iHead добавил 30.10.2011 в 17:18

'[umka:
;9602657']Я просто сторонник того, чтобы было как можно меньше всяких ненужных модулей/so и пр. :)
Да тут и делов-то — всего один файлик подменить.

я с вами согласен, но седня мне было в лом на всех серверах патчить PHP и пересобирать пых.

гемор продолжается.

если у вас крутится java (на сервере, например, tomcat, или локально, например iBank2), качаем tzupdater, распаковываем и делаем

java -jar tzupdater.jar -u

если на FreeBSD не обновляется (как у меня), тогда заходим в jar и копируем

\tzupdater.jar\data\tzdata2011k.zip\*

в папку с явой (jre\lib\zi\)

жесть :)

iHead добавил 30.10.2011 в 17:12

'[umka:
;9602491']timezonedb — это лишнее извращение.
Там вроде был скриптик, который из системной базы перетаскивает всё в пхп-шную.

тогда придется PHP пересобирать, а тут только модуль подцепить, который переопределит массив с зонами, который зашит в ext\date

iopiop:

не догоняю я этого :-(
разжуйте пожалуйста для идиота, почему 4, а не 8? в чем плюс четырех, а не восьми? для упрощения понимания предлагаю использовать систему где стоит только ngnix и отдает только статику.
спасибо.

гипертрединг не умножает реальную производительность на 2. нет у вас 8 ядер физически при гипертрединге на 4 ядерном проце. поставить можно 8, но будет ли от этого лучше неизвестно. скорее, узким местом окажется не процессор, а диск или сеть.

это все ИМХО.

iHead добавил 30.10.2011 в 01:34

babnicks:
Давайте кончать этот спор ни о чем :)

давайте.

доказывать ничего не хотел, да и не имею для этого глубоких знаний.

я слышал о них в марте 2007 года, появились, наверное, еще раньше.

нормальный срок :)

babnicks:
Я считаю что во всем нужна мера, и процессы которые действительно параллельны надо выполнять параллельно, если это не приводит к непомерным расходом на их диспетчеризацию, именно для этого создаются многопроцессорные ЭВМ и многоядерные процессоры ;)

В разумных пределах параллельное программирование действительно необходимость, такова природа вещей, как бы Вам не хотелось обратного ;)

параллельное программирование придумали для того, чтобы иметь возможность нагрузить процессор на 100% (ОС пока не умеют это делать самостоятельно), иметь возможность масштабировать задачу на десятки, сотни и тысячи компьютеров, чтобы либо обрабатывать больше данных либо обрабатывать одни и те же данные за разное (меньшее время).

если задача изначально распараллелена (тысячи запросов к веб-серверу), то нужны просто эффективные механизмы обработки. nginx пока с этим справляется эффективно без классических потоков.

iHead добавил 29.10.2011 в 21:33

netwind:
Тут не надо пытаться распараллелить, чтобы нагрузить второй процессор - он и так нагружен другими клиентами.

почти одно и тоже написали :)

netwind:
но ведь nginx работает достаточно эффективно и с отключенным sendfile и отключенным aio.

я не спорю. не используется одно, значит используется другое, что также эффективно работает без создания потоков внутри процесса.

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

babnicks:
😂 Это Вы ко мне приложили свои шаблоны не поняв о чем я говорю 😂

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

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

там намного сложнее все. в моем понимании основная работа перекладывается на ОС, например для отдачи файлов используется sendfile, остается только следить за событиями.

babnicks:
Просто слово вы выбрали не очень правильное, если бы написали псевдо-параллельно, то и придираться не стал бы :)

babnicks добавил 29.10.2011 в 15:10


Там много цифр и все разные :) основная масса колеблется около 30%

А вот Вы утверждали что:



Данное утверждение не верное и сильно не верное :)

ps: в реальных задачах ни разу не видел при HT прироста более чем на 30%

я говорил это для того, чтобы сказать, что ускорение меньше 2. для данной темы это было важно.

на тесте вычисления числа PI ускорение 1.5 (специально перепроверил).

1.6, видимо, когда-то у меня получалось поэтому эту цифру и назвал.

4 года назад я проходил стажировку в Intel по теме параллельных вычислений.

на лабах у нас были случаи, что ускорение при гипертрединге приближалось к двум (это т.н суперпараллельность), но конечно, это синтетические вычисления.

я не спорю, что на реальных приложениях будет 1.3 или еще меньше.

Всего: 870