Re: к вопросу о производительности FB
Может покажусь нудным, но на самом деле, знания о том, что выдавил из сервера все что мог,а дальше нужно нарашивать железо и определяют специалиста, достойного оплаты от Да, это точно. Где б таких спецов найти... Поскольку тема подходящая, спрошу заодно. Может кто поможет. Вообщем чувствую я, что из своего сервера под линуксом я далеко не все выдавил. Вкратце : Материнка Asus, проц - P4 3 Гц, памяти 2 гига, 4 SATA. Вообщем немного усиленная рабочая станция. Порядка 30 рабочих станций. На сервер взгромаздил все. DNS, DHCP, Samba в качестве контроллера домена и FB (знаю, что плохо). Из дисков сделал 2 зеркала. На одном зеркале стоит система и Samb-овские шары. На втором - FB. По ночам делается backup файлов с одного зеркала на другое и наоборот соответственно. Вообщем старался добиться максимальной надежности. Сейчас замечаю, что под виндой вообщем-то поживее как-то было. Хотя на тоже на одном сервере все установлено было. Единственное что не было софтового зеркала... Установил утилитку, которая показывает загрузку системы. Вообщем узкого места не обнаружил. Своп практически не используется. Процессор загружен процентов на 10. Скопировал большой файл с сервера на рабочую станцию. В этот момент нагрузка на диски и сетевую карту увеличилась. А так, в обыкновенном режиме, видно, что нагрузка на диск и сетевую не достигает тех значений, которые были при копировании большого файла... Вообщем может кто подскажет как определить узкое место. Ну и что улучшить можно при описанном раскладе. Пока пришло в голову (чего-то сразу не сообразил, пока систему ставил), что надо бы сделать raid-диск c чередованием и на нем разместить все временные файлы. Насколько эффективно будет перекомпилировать ядро? Стоит ли скомпилить FB? Может в настройках дисков покопаться? (как не знаю кстати). Может еще какие настройки системы есть, на которые стоит обратить внимание... With b/r. Gleb.
Re: к вопросу о производительности FB
Мадорский Г.В. wrote: Насколько эффективно будет перекомпилировать ядро? Лучше не надо. Стоит ли скомпилить FB? Это, кстати, интересный вопрос. Можно попробовать собрать со всеми оптимизациями и под конкретный процессор. Может в настройках дисков покопаться? (как не знаю кстати). man hdparm -- Oleg
Re: к вопросу о производительности FB
Вкратце : Материнка Asus, проц - P4 3 Гц, Сдай в утиль, купи QUAD. Типа 6600 (2.4G) - он щас вообще копейки стоит. И памяти ~4GB, если не DDR3 - тоже смешные деньги. И не парь себе моск. У меня однопоточные тяжеловестные вещи в полтора раза быстрее стали трудится. И это под Vista Ultimate x64 Не говоря про реальную возможность разведения зоопарка на такой машине :-) Был XP+ASUS+прескотт 2.8+3.2GB+RAID0 из двух SATA ... правда HDD тоже поменял. Я вообще все поменял :-) Коваленко Дмитрий.
Re: к вопросу о производительности FB
Мадорский Г.В. [EMAIL PROTECTED] сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] Вообщем чувствую я, что из своего сервера под линуксом я далеко не все выдавил. У нас тоже такая проблема ... была :-) Единственное что не было софтового зеркала... Вот здесь основная проблема. Нужно делать аппаратный рэйд. По два диска в зеркало и на них страйп. (все время путаю кто 10 и 01). Настройки рэйда: Размер страницы БД = Размер буфера диска. Размер блока страйпа = 2*Размер буфера диска. -- Галимов Артур Амирзянович. ФармМедСервис (Сочи).
Re: к вопросу о производительности FB
Качановский Дмитрий пишет: Это я к тому насколько эффективно можно работать в FB с таблицами миллионниками. В часы пик в среднем происходит 6-10 операций добавления/изменения в секунду. И это всего лишь мнимальная часть, того что происходит при подготовке страниц. таблица momdata (туда сгоняются параметры с примерно 250 приборов учета в реальном времени) структура DEVID Integer, TYPEDEVICE Integer, CHANNELID Integer, ARDTIMESTAMP Timestamp, DOUBLEVALUE Float, DATETIMEWRITE Timestamp индексы CREATE INDEX IDX_MOMDATA ON MOMDATA (DEVID,ARDTIMESTAMP,CHANNELID,TYPEDEVICE);CREATE INDEX IDX_MOMDATA1 ON MOMDATA (ARDTIMESTAMP); CREATE DESCENDING INDEX IDX_MOMDATA2 ON MOMDATA (ARDTIMESTAMP); CREATE INDEX IDX_MOMDATA3 ON MOMDATA (DEVID,TYPEDEVICE); CREATE INDEX IDX_MOMDATA4 ON MOMDATA (DEVID,TYPEDEVICE,CHANNELID,ARDTIMESTAMP); количество всего записей 158606000 количество влетающих за день записей 7603275 ы? ;)
Re[2]: к вопросу о производительности FB
Привет! количество всего записей 158606000 количество влетающих за день записей 7603275 Плятт. Я только вчера в архитекте написал, что мне трудно представить базу с миллиардом записей. -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: к вопросу о производительности FB
Sergey Mereutsa пишет: Привет! количество всего записей 158606000 количество влетающих за день записей 7603275 Плятт. Я только вчера в архитекте написал, что мне трудно представить базу с миллиардом записей. и это еще раз в сутки удаляются записи where ardtimestamp (current_date - 15) :)
Re: к вопросу о производительности FB
и это еще раз в сутки удаляются записи where ardtimestamp (current_date - 15) Может покажусь нудным, но на самом деле, знания о том, что выдавил из сервера все что мог,а дальше нужно нарашивать железо и определяют специалиста, достойного оплаты от Дмитрий
Re[2]: к вопросу о производительности FB
Привет! и это еще раз в сутки удаляются записи where ardtimestamp (current_date - 15) Может покажусь нудным, но на самом деле, знания о том, что выдавил из сервера все что мог,а дальше нужно нарашивать железо и определяют специалиста, достойного оплаты от Ты не поверишь, но есть спецы, кривость рук которых зачастую компенсируется мощностью железа. Я лично видел, как 8(!) процессорный ксеон с 16(!) гигами оперативки со сказевыми винтами просто лежал... генерируя 700-метровые отчеты о тотальном сканировании дискового массива каждые 5 минут... -- Best regards, Sergeymailto:[EMAIL PROTECTED]
Re: к вопросу о производительности FB
DmitryLe пишет: и это еще раз в сутки удаляются записи where ardtimestamp (current_date - 15) Может покажусь нудным, но на самом деле, знания о том, что выдавил на самом деле нам бы сейчас специалист не помешал. потому что использовать ФБ на таких обьемах с моими куцыми знаниями трудновато. читаю доки, мозги закипают. Да еще kdv меня на ФАК послал :)
к вопросу о производительности FB
не ради того что бы праздно похвастаться а только ради того дабы подчеркнуть крутость всеми нами любимого... Есть у меня табличка в которой учитывается сколько раз за последний час пользователь посмотрел на баннер и сколько раз на него нажал. Операции: добавление записи, когда происходит первый показ/клик баннера в часу и обновление записи при повторных показах/кликах. Таблица проходная, так как с ее данных сразу же тригерами формируется сводная почасовая статистика по баннеру в другой таблице, т.е. через час, по большому счету, информация в ней становится ненужной. Но как то так не реализовал я очистку устаревшей информации (любопытно было посмотреть к чему это приведет), в результате на текущий момент в таблице 21 млн. записей. Это накопилось за полгода. Это я к тому насколько эффективно можно работать в FB с таблицами миллионниками. В часы пик в среднем происходит 6-10 операций добавления/изменения в секунду. И это всего лишь мнимальная часть, того что происходит при подготовке страниц. -- С уважением Качановский Дмитирй ООО КОШТпроект
