Re: Интеллектуально-ролевая игра Золотой Клон
Hello, Pupc! You wrote on Thu, 28 Jun 2007 01:07:11 -0700: P Интеллектуально-ролевая игра Золотой Клон - играйте и Вот ведь, блин, загадка природы - от нормальных людей писем нету, а всякие золотые клоуны - пррываются... :\ With best regards, Vladimir A.Bakhvaloff. E-mail: [EMAIL PROTECTED]
Re: Интеллектуально-ролевая игра Золотой Клон
Vladimir A.Bakhvaloff wrote: Hello, Pupc! You wrote on Thu, 28 Jun 2007 01:07:11 -0700: P Интеллектуально-ролевая игра Золотой Клон - играйте и Вот ведь, блин, загадка природы - от нормальных людей писем нету, а всякие золотые клоуны - пррываются... :\ так это спам-фильтр работает... он все кроме спама фильтрует :)
Re: Наверное уже написал кто-нибудь...
On 27 июн, 13:48, Мадорский Г.В. [EMAIL PROTECTED] wrote: Всем привет. Я все потихоньку с Linux вожусь. Вроде перетащил все. Работает. Поднял домен под samba, DHCP, DDNS, SQUID. Очень rsync понравился. Если я правильно помню ты начал эксперименты с линуксом достаточно давно. Оправдал ли себя переход ? Доволен ли ты ? Начальство ? Рядовые юзеры ? Я понимаю, что за windows и т.п. тоже нужно платить, но и рабочее время (освоение линуквса, решение проблем, сам переход) тоже стоит недешево. Будет ли рассказ о глобальном переходе ? Уж больно мне твои рассказы о путешествиях нравится читать :-)
Re: Наверное уже написал кто-нибудь...
Graur Stanislav wrote: Будет ли рассказ о глобальном переходе ? Уж больно мне твои рассказы о путешествиях нравится читать :-) Картина маслом: Глеб верхом на пИнгвине пересекает Южно-Мумуйский хребет :-D -- Regards. Ded.
Re: OFF: Разгон машины тьюринга :)))
Смотря какая природа у этого варианта. У меня сейчас два потока работают - один грузит данные из базы - второй эти данные обрабатывает. В идеале первый поток не нужен. Странные у тебя идеалы :) Я бы сделал работу следующим образом: поток-читатель считывает из базы блок данных и передаёт его на обработку второму потоку через PostThreadMessage (по старинке) или QueueUserAPC (по современному). Размер блока данных подбирается чтобы его обработка занимала примерно полсекунды. Я это сделал через буфер обмена, защищенным критческой секцией. проблема в том, что первый успевает насытить буфер с исходными данными под завязку, а второй пашет как ненормальный что бы этот буфер освободить, но очень редко когда его опустошает. А проблема то в чем? Конечно, при любых алгоритмах нужно приостанавливать фетч если данные обрабатываются медленно. Он у меня приостанавливается :) У меня даже фоновый поток выгрузки модифицированных страниц может завершаться, когда у него нет работы. Правда, работой его по самую макушку заваливают. И ещё, получается что у тебя обработка данных занимает времени намного больше чем их выкачка из базы. В такой ситуации выигрышь от распараллеливания невелик в процентом отношении. Иногда буфер все таки опустошается. Это когда сервер начинает чухаться с подгрузкой нужной части данных в свой кэш. --- Вообщем, текущее положение дел с машиной тьюринга такое. - Я прикрутил фоновый поток выгрузки модифицированных страниц. - Послушал как работает машина (в натуре на слух), и понял - нужно нафиг отключить буферизацию файловых операций. То бишь указал флаги FILE_FLAG_WRITE_THROUGH, FILE_FLAG_NO_BUFFERING - Это потребовало заюзать память, выделяемую через VirtualAlloc. Типа, как завещал Великий LOA :) - Гудение винтов стало равномерным :) (кстати пару раз слышал странные щелчки) - Посмотрев на это дело, я понял что бежать больше некуда и надо доделывать менеджер кэша - в него писать не через read/write функции, а напрямую. И переделать управление хеш-таблицей - отказаться от мелких блоков, а перейти к блокам занимающим всю страницу целиком. Продолбенился над реализацией целый день. Получилось красиво. И - о чудо! У меня многопоточная реализация стала работать вровень с однопоточной. Более того - может это меня заглючило (в 3 часа ночи) - даже немного быстрее. Вообщем, системные затраты стали очень маленькими и диспетчер задач светился радостным зеленым цветом. Одним из забавных моментов была при обработке какой-то порции данных, когда общая нагрузка на процессор (HT включен) плавно поднималась с 50 до 100, там держалась, а потом плавно опускалась. Возможно это связано с увеличением числа попаданий в локальные кэши каждого потока. Хотя по правде - шайтан его знает, с чем это связано. -- Но, плят, щастье длится ровно столько сколько заполняется кэш. Напомню, мне нужно построить уникальный индекс для (по последним прогнозам) 100 лимонов элементов вида (ID1, ID2). Максимум что я смог осилить - 20 лимонов. Сейчас, для построения индекса элементов, юзаю хеш-таблицу. По формуле (ID1+ID2)/HashTableSize определяю элемент таблицы. В элементе хранится указатель на упорядоченный блочный список. Блок списка равен размеру страницы (4K). Фоновый поток выгружает самые старые модифицированные страницы. Но, судя по индикации счетчиков размеров списков чистых и грязных страниц, в эти очищенные страницы сразу же срут и они возвращаются в очередь грязных страниц. Скорость генерации очень высокая - программа только начинает работать, а уже сразу выжирает под 30-40 тысяч страниц. И дальше очень интенсивно гадит в каждую из них. После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Я пробовал останавливать потоки генерации, что бы дать выгружателю сбросить все на диск - эффект мизерный. После того как генераторы возобновляют работу - производительность не повышается и очередь грязных страниц неулонно растет. Это зарезало мою идею уменьшать приоритет генераторов при катастрофическом загрязнении кэша. Пробовал играть и с размером страниц и c HashTableSize - общая картина не улучшается. -- Мне кажется что проблема все таки в самой hash-таблице. Точнее в стоимости добавления нового элемента в существующий список. Если программа способна генерировать свыше 20 тыс уникальных комбинаций в секунду, и каждая из них попадает в свой список хеш-таблицы, то тут ничего не спасет. Я же, блин, постарался - отсортированность поддерживаю. Так что тут еще и уже заполненные блоки списков могут модифицироваться... Сейчас буду прикладывать к голове умную книжку с описанием конструкции Б-деревьев. -- Не, но многоточность я таки победил. Честное пионерское :) ... Как сложно делать простые вещи. И какими сложными они потом оказываюся :( Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Kovalenko Dmitry ... После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Грязные страницы на диск идут в каком порядке ? Как попало ? -- Хорсун Влад
Re: Наверное уже написал кто-нибудь...
Graur Stanislav wrote: Будет ли рассказ о глобальном переходе ? Уж больно мне твои рассказы о путешествиях нравится читать :-) Картина маслом: Глеб верхом на пИнгвине пересекает Южно-Мумуйский хребет :-D Меня больше интересуют нюансы путешествия: что пил, что курил. Пришлось ли покупать новый бубен ? :-) Были ли нападения озлобленных юзеров ? :-) Я тут часть народа пересадил под OpenOffice, месяц был врагом народа. Потом надоело, пригрозил стереть все игры, музыку и фильмы... Народ разумно заметил, что и под OpenOffic-ом тоже можно жить.
Re: Наверное уже написал кто-нибудь...
Картина маслом: Глеб верхом на пИнгвине пересекает Южно-Мумуйский хребет :-D Меня больше интересуют нюансы путешествия: что пил, что курил. Пришлось ли покупать новый бубен ? :-) Были ли нападения озлобленных юзеров ? :-) Я тут часть народа пересадил под OpenOffice, месяц был врагом народа. Потом надоело, пригрозил стереть все игры, музыку и фильмы... Народ разумно заметил, что и под OpenOffic-ом тоже можно жить.
Re: OFF: Разгон машины тьюринга :)))
После заполнения кэша (я эксперементирую с кэшем на 120 тыс четырех килобайтных страниц) производительность падает до копеечных размеров. Грязные страницы на диск идут в каком порядке ? Как попало ? Угу. - Беру последнюю страницу из очереди грязных страниц. - Блокирую её от записи - Пишу на диск - Убираю из списка грязных страниц - Начинаю с начала Возможно упорядочивание как-то поможет. Это значит я должен заблокировать группу страниц, упорядочить, выгрузить... Но, кажется, проблема не в этом. Нужно компоновать данные так, что бы заполненные блоки списков хеш-таблицы больше не модифировались. Это увеличит время проверки - после заполнения кэша, возникнут ситуации с загрузкой всех блоков какого-то списка. Но модифицироваться будет только последний блок. Остальные потом вытесняться из кэша без накладных расходов. Внутри блоков поддерживать упорядоченность. Длину списков можно регулировать увеливая HashTableSize. Цена проверки гипотезы - пара часов, не больше :) (сказал русский программист, гы) Коваленко Дмитрий.
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA wrote: Kovalenko Dmitry [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] как завещал Великий LOA :) Недождётесь :-) Оффну слегонца. Ты, помнится, пару раз на работу людей брал. Не сдашь координаты двойки-тройки лучших из худщих, в смысле непрошедших отбор? У меня тут, похоже, потихоньку наклёвывается вакансия. Ну по профилю - FB-Delphi, документооборот, бюстгальтэрия, планирование-буджетирование... Здешние-то, знакомые, все при делах скорей всего, а искать свободным поиском влом - это ж десятки перебрать придётся. -- Regards. Ded.
Re: Наверное уже написал кто-нибудь...
Привет. Если я правильно помню ты начал эксперименты с линуксом достаточно давно. Оправдал ли себя переход ? Говорить об этом рановато. Типа сейчас опытная эксплуатация. Пока полет нормальный. Доволен ли ты ? Опять же рановато говорить. Доволен пока тем, что с linux поподробнее познакомился. Начальство ? Начальство довольно. У него-то XP осталось :))) Рядовые юзеры ? Да вообщем-то нормально. По поводу того, что в игрушки не поиграть никто впрямую возмущаться не будет. А попыток саботажа вроде не наблюдается пока... Я понимаю, что за windows и т.п. тоже нужно платить, но и рабочее время (освоение линуквса, решение проблем, сам переход) тоже стоит недешево. Тут опять же сложно говорить. На покупке ПО где-то 12 000$ сэкономили по самым скромным подсчетам. А вот сколько времени потратил, и еще потрачу - фиг скажешь. Я ж ведь и обычные дела при этом делаю. Будет ли рассказ о глобальном переходе ? Уж больно мне твои рассказы о путешествиях нравится читать :-) Это уже пятничная тема... Попробую завтра, если жив буду. Я вообще с ужасом ожидаю завтрашнего дня. Дело в том, что я на два фронта тружусь. Так вот сегодня вечером на второй работе отмечается очередной ДР фирмы. Без потерь оттуда не уйти. Каждому ведь просто необходимо чокнуться с любимым программистом. :) Окромя всего прочего дамская половина там очень даже... А завтра на первой работе хозяин фирмы из отпуска возвращается. Ну и конечно же чего-нибудь пообсуждать ему захочется... И какой это я буду? Интересное видимо мнение у него будет о том, как доблестно трудится служба IT пока он в отпуске... А сегодня у другого хозяина фирмы вирусы компьютер похерили нафиг. Завтра оживлять как-то надо. NOD32 - это ужас просто. Купил на свою голову... With b/r. Gleb.
Re: �������� ��� ������� ���-������...
Здравствуйте, Мадорский. Вы писали 27 июня 2007 г., 14:48:48: Хочу хранить логи SQUID и IPTABLES. У меня так оно и есть. Разные базы под FB1.5, правда под виндой. Я логи кажодое утро с сервера по ftp стягиваю и уже на винде дельфевой самопиской обрабатываю. squidlog просто разбираю и в базу заливаю, оттуда отчетики поюзерно. По iptables. Готового и рабочего решения не нашел. Используем логирование средствами iptables по iplog в /var/log/messages. При ротации messages из него отгрепливаются строки с названиями правил iptables. Из самого messages данные iplog удаляются - очень уж много получается, чуть ли не 1:1 с самим логируемым трафиком. Однако потом маета их обрабатывать. У меля получалось отгрепленный messages порядка 100-200мб в сутки. И обрабатывался он, правда нифига не оптимальным способом порядка 30-40 минут. Потом в базе сворачивал (агрегировал) исходные данные с точностью до минуты но из-за массового install-delete пухнет база. Однако после того как при ловле спам рассыльщиков и протчего messages выжрал все место на сервере и потом пришлось его неделю обрабатывать решили переделать по другому. iptables умеет писать логи через ulog. Точнее он может выдавать данные по обрабатываемым пакетам в определенном формате. Ловить эти данные должна специальная программа. Одна из них называется ulog-acctd или примерно так, на память не очень надеюсь. И этот вот сборщик умеет агрегировать данные за заданный период. допустим каждые 5 минут он сбрасывает полученные агрегаты в свой лог а каждый час этот лог ротируется. Т.е. вытаскивать данные можно с давностью до часа. Уже почти онлайн. Причем формат лога от ulog-acctd настраивается, можно даже сделат так что бы он в виде insert-скрипта выводился. Мне было удобнее сделать его в типа csv да там по дефолту почти так и есть. Файлики получаются весьма небольшие. В базу я их заливаю только для того что бы в помощью sql посмотреть агрегаты или проанализировать по протоколам, портам и IP. Держать данные в базе более 2-х месяцев смысла нет. Исходные логи если пожать - хранятся весьма компактно и всегда при необходимости можно их залить в базу и посчитать что надо. Однако замечен косяк. Когда один из абонентов подхватил агента DoS-атак и он сработал - ентот биллинг через ULOG сильно обсчитался в бОльщую сторону. За время атаки траф увеличил раза в 3. В остальное время - вопросов не было. maillog разбираю программкой SMA - получаю весьма прозрачный лог одно письмо - одна строка. Правда если в мыле не указан домен - невозможно достоверно определить откуда и куда это было. SMA есть и под винду и под линух. Формат лога так же настраивается, хоть до insert-скрипта. Полученное заливаю в базу и потом даже не стал делать прикладуху - просто из IBExpert вызываю процедурки. -- С уважением, Владимир mailto:[EMAIL PROTECTED]
Re: FB Vista
Oleg Prosvetov wrote: Подскажите какой дистр FB нормально устанавливается и работает под Windows Vista ? Все, но с разными побочными эффектами. -- Дмитрий Еманов
Re: OFF: Разгон машины тьюринга :)))
Oleg LOA wrote: Бюджет-то какой? Может кого сам порекомендую из знакомых. 3 месяца испытательного - $800, потом - 1500 с гарантированным ростом в обозримое время по успехам. Если всё пойдёт - до 2000 точно, а дальше уже будет зависеть не только от успешности деятельности и от меня, а и от настырности и гибкости самого человека в отношениях с боссом. Работа будет тяжелая - без ТЗ, на слух, и внутренняя дока по действующему по нулям. На вопросы по мере возможности отвечаем. Если вспоминаем. -- Regards. Ded.
Re: Наверное уже написал кто-нибудь...
Hello, Stanislav! Graur Stanislav wrote: Я тут часть народа пересадил под OpenOffice, месяц был врагом народа. Потом надоело, пригрозил стереть все игры, музыку и фильмы... Народ разумно заметил, что и под OpenOffic-ом тоже можно жить. диктатор :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Кто занимается переименованием имён полей?
sasha wrote: Кх-кх Понимаешь какое дело. Наступив единожды в отрочестве на эту граблю, каждый из присутствующих принял для себя решение писать запросы так, чтоб впоследствии на неё не наступать. То есть, * по возможности не пользоваться, ну разве что в простейших селект фром табле или процедуре. И при возможности возникновения какой-либо неодназночности прям щас или в будущем пользуется алиасами полей. Посему внятного ничего сказать не можем. Ну типа да, где-то там в Ираке стреляют, мир несовершенен... -- Regards. Ded.
Re: FB Vista
Dmitry Yemanov wrote: Все, но с разными побочными эффектами. :-
OFF Наших бъют....
Что то банировцы мне опускать начали. Конечно статья не про FB, но просба прочесть и высказаться ( с учетом того что писал програмист :) ). http://bankir.ru/analytics/classic/kredit/352/89061
Re[2]: ��� ���������� ��������������� ���� ����
Здравствуйте, Ded. Вы писали 29 июня 2007 г., 0:19:15: И при возможности возникновения какой-либо неодназночности прям щас или в будущем пользуется алиасами полей. Кстати - да :) Не помню уже что меня к этому повернуло но сейчас каждый запрос который встраивается в приложение а не вводится в IBE в интерактиве в обязательном порядке поля поименовываются через as даже если это новое имя такое же как старое. -- С уважением, Владимир mailto:[EMAIL PROTECTED]
Re: Кто занимается переименованием имён полей?
Hello, бКЮДХЛХП! You wrote on Thu, 28 Jun 2007 02:46:13 +0700: И при возможности возникновения какой-либо неодназночности прям щас или в будущем пользуется алиасами полей. бю Кстати - да :) бю Не помню уже что меня к этому повернуло но сейчас бю каждый запрос который встраивается в приложение бю а не вводится в IBE в интерактиве в обязательном бю порядке поля поименовываются через as даже если бю это новое имя такое же как старое. Это имхо уже лишнее. Сдуру, как известно, можно и кое что сломать. Надо - делай алиас. Не надо - не делай. Кстати, as можно опустить. -- Удач Alexander A. Venikov, Tobolsk, Russia
Re: Наверное уже написал кто-нибудь...
Ну вот, так я и думал. Блиин... With b/r. Gleb.
