Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Oleg LOA said the following on 15.09.2006 13:38: >> Не смеши людей. Все это железо в линуксе работает ничем не хуже чем >> в винде. > > Угу, а "ответы на вопросы" это для марсиан :-). Если отсутствие > поддержки того функционала ждя которого этого железа часто и > приобретается есть "ничем не хуже чем в винде", то тоды ой как > говорится. Никто не заставляет использовать драйверы которые входят в ядро. Если их функционала не хватает, используй "proprietary, binary-only drivers" - от LSI или от Adaptec. Другое дело что обычно смысла в этом, действительно мало. Меня абсолютно устраивает софтовый линуксный raid, но и потребности у меня небольшие. А у кого потребности большие - у того хватит денег и на более серьезное железо и на его поддержку ;-) -- Oleg
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
"Oleg Deribas" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Не смеши людей. Все это железо в линуксе работает ничем не хуже чем в винде. Угу, а "ответы на вопросы" это для марсиан :-). Если отсутствие поддержки того функционала ждя которого этого железа часто и приобретается есть "ничем не хуже чем в винде", то тоды ой как говорится.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Oleg LOA said the following on 15.09.2006 10:31: >> Почему же, всё это железо поддерживается и работает. Смотри пункты >> 8 и 9. > > Это железо работает как обычный ATA контроллер. Тебе понравится когда > дрова твоего цветного лазерного принтера будут поддерживать только > ЧБ-печать? Это не поддержка, это возможность работать с железом. Не смеши людей. Все это железо в линуксе работает ничем не хуже чем в винде. -- Oleg
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Oleg LOA пишет: "Yakov Hrebtov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Почему же, всё это железо поддерживается и работает. Смотри пункты 8 и 9. Это железо работает как обычный ATA контроллер. Тебе понравится когда дрова твоего цветного лазерного принтера будут поддерживать только ЧБ-печать? Это не поддержка, это возможность работать с железом. Согласен, dmraid содержит не всю функциональность софта от производителей, а только её главную часть: программную реализацию raid - зеркалирования/чередования дисков. Просто речь не о полноте поддержки, а о способе реализации raid-функциональности в данных устройствах. Способ этот _программный_. Можно поставить родной драйвер от производителя, тогда раскидывать данные по дискам будет он. Не контроллер, а драйвер. С использованием процессорного времени системы. Можно использовать родной линуксовый модуль dmraid. Или можно работать с контроллером через INT 13H :) вообще без драйверов, тогда раскидывать данные по дискам будет ПО в БИОСЕ контроллера. Опять же используя CPU системы. Аппаратные RAID, стоят дорого и на материнках ставятся редко (я не видел).
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
"Yakov Hrebtov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Почему же, всё это железо поддерживается и работает. Смотри пункты 8 и 9. Это железо работает как обычный ATA контроллер. Тебе понравится когда дрова твоего цветного лазерного принтера будут поддерживать только ЧБ-печать? Это не поддержка, это возможность работать с железом.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Oleg LOA пишет: Гм, это ответы в стиле: "Да мне пох на ваши арбузы...у меня есть дыни". Ну нет финансовых возможностей поддреживать всю эту кучу железа, вот и ответы такие. Почему же, всё это железо поддерживается и работает. Смотри пункты 8 и 9.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
"Yakov Hrebtov" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Вот, кстати, наткнулся на мнение > разработчика linux драйверов SATA > устройств по данному вопросу: > http://linux-ata.org/faq-sata-raid.html Гм, это ответы в стиле: "Да мне пох на ваши арбузы...у меня есть дыни". Ну нет финансовых возможностей поддреживать всю эту кучу железа, вот и ответы такие.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Yakov Hrebtov wrote: > Большинство raid на материнках (задрипанных и не очень) -- софтовые. Они ни > чем не лучше, чем > raid средствами операционки. А порой даже и хуже. Вот, кстати, наткнулся на мнение разработчика linux драйверов SATA устройств по данному вопросу: http://linux-ata.org/faq-sata-raid.html
Re: OFF:? Фрагментация файла БД ...
Sergiy S. Tkachenko wrote: Ребята, которые работают на Южной Железной Дороге Украины используют InterBase 5 и у них постоянно идёт дефрагментация раздела с базой данных стандартным виндовским дефрагментатором. Никто базу данных не останавливает. А чего ее останавливать? Виндовский дефрагментатор занятые файлы не трогает :-) По крайней мере, так в описании сказано.
Re: OFF:? Фрагментация файла БД ...
Alexandr Kochmin пишет: Я давно хотел спросить http://www.trichview.ru/ это твое, или однофамилец? Нет, он в Москве, а я в Кременчуге. Моё было(или ещё есть) тут http://4thfebruary.tripod.com
Re: OFF:? Фрагментация файла БД ...
К> Не не моё ... не... ты в ветках запутался. Я не у тебя спрашивал ;) -- С уважением Кочмин Александр
Re[2]: OFF:? Фрагментация файла БД ...
SST>> SST>> Dmitri Kuzmenko пишет: SST>>> SST>>> diskeeper 8-9-10 работает отлично, сбоев ни разу, SST>>> может дефрагментировать файлы in use. SST>>> SST>> Вот, а Константин не верит. SST>> AK> Я давно хотел спросить AK> http://www.trichview.ru/ AK> это твое, или однофамилец? Не не моё ... С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
SST> SST> Dmitri Kuzmenko пишет: SST>> SST>> diskeeper 8-9-10 работает отлично, сбоев ни разу, SST>> может дефрагментировать файлы in use. SST>> SST> Вот, а Константин не верит. SST> Я давно хотел спросить http://www.trichview.ru/ это твое, или однофамилец? -- С уважением Кочмин Александр
Re[2]: OFF:? Фрагментация файла БД ...
SST> Dmitri Kuzmenko пишет: >> >> diskeeper 8-9-10 работает отлично, сбоев ни разу, >> может дефрагментировать файлы in use. >> SST> Вот, а Константин не верит. Уже верю ... :) Всем громадное спасибо ... С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
Dmitri Kuzmenko пишет: diskeeper 8-9-10 работает отлично, сбоев ни разу, может дефрагментировать файлы in use. Вот, а Константин не верит.
Re: OFF:? Фрагментация файла БД ...
Привет, Karabas! Вы пишешь к Alexey Popov 11 сентября 2006: AP>> Полная аналогия с файловой системой - чем больше размер AP>> кластера тем больше жрут места мелкие файлы. KB> Это становится не смешно Наоборот! :о))) -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ...
Hi Alexey Popov ! AP> Полная аналогия с файловой системой - чем больше размер AP> кластера тем больше жрут места мелкие файлы. Это становится не смешно -
Re: OFF:? Фрагментация файла БД ...
Dmitry Voroshin wrote: Ничего не понял... Полная аналогия с файловой системой - чем больше размер кластера тем больше жрут места мелкие файлы. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ...
"Alexey Popov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > > > Dmitry Voroshin wrote: > > > А может твоя разница от неполного заполнения страниц была? Может стоило > > включить 100% заполнение страниц и разница бы исчезла? > > Не, база часто обновляемая. > > Да и не спасло бы имхо. Т.к. это обычно это потерянное пространство > в не до конца заполненных страницах. > Ничего не понял...
Re: OFF:? Фрагментация файла БД ...
Dmitry Voroshin wrote: А может твоя разница от неполного заполнения страниц была? Может стоило включить 100% заполнение страниц и разница бы исчезла? Не, база часто обновляемая. Да и не спасло бы имхо. Т.к. это обычно это потерянное пространство в не до конца заполненных страницах. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ...
"Alexey Popov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > > > Dmitry Voroshin wrote: > > > Ну и чего ты тогда выиграешь создав 1k страницу? > > Давно это было. Разница была ощутимой. А может твоя разница от неполного заполнения страниц была? Может стоило включить 100% заполнение страниц и разница бы исчезла?
Re: OFF:? Фрагментация файла БД ...
Dmitry Voroshin wrote: Ну и чего ты тогда выиграешь создав 1k страницу? Давно это было. Разница была ощутимой. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Alex Cherednichenko пишет: Привет, Yakov! Вы пишешь 11 сентября 2006: YH> Это самый натуральный hostraid. Еще их называют fakeraid :-) YH> Отличие raid на этих чипсетах от обычного софт-рэйда в том, что софт этот размещен в биосе YH> контроллера, а не в ядре (модуле ядра) ОС. Я тебя наверное огорчу, но во ВСЕХ RAID-контроллерах есть свой БИОС БИОС то есть во всех, только для реализации основных функций контроллера он используется только у софт-рэйдов, таких как ICH5,6,7... > А описалово ты таки не читал... Описание производителя я читал (http://www.intel.com/design/chipsets/applnots/30264802.pdf). Только там эти низкоуровневые моменты мягко обходятся стороной ;-) Еще бы! Железяку то продавать надо... В дальнейшем "диспуте" со "специалистами" не участвую. Да, смысла в этом нет.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Yakov! Вы пишешь 11 сентября 2006: YH> Это самый натуральный hostraid. Еще их называют fakeraid :-) YH> Отличие raid на этих чипсетах от обычного софт-рэйда в том, что софт этот размещен в биосе YH> контроллера, а не в ядре (модуле ядра) ОС. Я тебя наверное огорчу, но во ВСЕХ RAID-контроллерах есть свой БИОС А описалово ты таки не читал... В дальнейшем "диспуте" со "специалистами" не участвую. -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ...
"Alexey Popov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > > Dmitry Voroshin wrote: > > > На эти 500 кил у тебя 500 таблиц? > > Ну не 500, а ~50 будет Ну и чего ты тогда выиграешь создав 1k страницу?
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Alex Cherednichenko пишет: Почитай описание ICHR5,6,7 Если возникнут возражения, спрашивай. Это самый натуральный hostraid. Еще их называют fakeraid :-) Отличие raid на этих чипсетах от обычного софт-рэйда в том, что софт этот размещен в биосе контроллера, а не в ядре (модуле ядра) ОС. raid-функциональность обеспечивается программно этим самым софтом. Доказательством фэйка является доступность самих дисков мимо рэйд-устройства. В железных рэйд контроллерах такого не бывает никогда.
Re: OFF:? Фрагментация файла БД ...
Dmitry Voroshin wrote: На эти 500 кил у тебя 500 таблиц? Ну не 500, а ~50 будет -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ...
"Alexey Popov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > > > Dmitry Yemanov wrote: > > >> А лопатой по спине? Кто такие бредовые идеи генерит? > > > > Я. > > "Государство - это я" (с) > > >> У меня мелкие базы которые именна на 1к работают. > > > > > > И нафуя? Даже на 20МБ базе страница в 4К дает увеличение > > производительности по сравнению с 1К. > > Гыыы 20Мб.! 500кил не хочешь? Системы аля управление > артогнём в танке абрамс. > Производительность - в печку. Тут главное компактность > и мобильность. На эти 500 кил у тебя 500 таблиц?
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Аппаратный raid позволяет сделать зеркалирование не дисков целиком, а выбранных разделов? нет. А смысл? Я на серверы самого начального уровня (для мелких филиалов) обычно ставлю два SATA диска. Зеркалируется система и раздел с критичными данными. И остается еще два крупных раздела под всякий хлам, смысла в зеркалировании которого не вижу. Давайте так - я считаю программный raid бессмыслицей, несмотря на письмо Артура Галимова. Т.е. как я и предположил, это из области личных пристрастий, которые нет большого смысла обсуждать. Вполне понятно и естественно - у многих есть подобные предубеждения по разным вопросам, имеющим несколько относительно равноценных решений.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Yakov! Вы пишешь 11 сентября 2006: >> Товарищ не понимает... (С) YH> Поясни плиз, а то твоего замечания действительно не понял :) Почитай описание ICHR5,6,7 Если возникнут возражения, спрашивай. -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ...
Dmitri Kuzmenko wrote: базы со страницей 1К практически всегда тормозят, и очень хреново ремонтируются (дольше, и больше денег). А может лучше в консерватории подправить? База целиком влезет в озу и тормозит. Кстати не замечал. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Alex Cherednichenko пишет: Привет, Yakov! Вы пишешь 11 сентября 2006: YH> Большинство raid на материнках (задрипанных и не очень) -- софтовые. Товарищ не понимает... (С) Поясни плиз, а то твоего замечания действительно не понял :)
Re: OFF:? Фрагментация файла БД ...
Dmitri Kuzmenko wrote: с 1К FB2 будет работать Речь про 2.1, вообще-то :-) -- Дмитрий Еманов
Re: OFF:? Фрагментация файла БД ...
Dmitry Yemanov wrote: А лопатой по спине? Кто такие бредовые идеи генерит? Я. "Государство - это я" (с) У меня мелкие базы которые именна на 1к работают. И нафуя? Даже на 20МБ базе страница в 4К дает увеличение производительности по сравнению с 1К. Гыыы 20Мб.! 500кил не хочешь? Системы аля управление артогнём в танке абрамс. Производительность - в печку. Тут главное компактность и мобильность. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ...
Hello, Boris! Boris Loboda wrote: 1024, заливал iso на 600Mb. Садо-мазо ? :) Ну почему же. Просто тестирование на предельных углах атаки. :-) Вообще-то у меня лично в заливке даже таких объемов практической потребности не возникало. речь про 1к page size. Причем повторюсь, в доке четко говорится что для 1к блоб не может быть больше 64мб. Соответственно, ты поделил 64мб на 1к, и получил "64 к страниц". Что не соответствует истине для других размеров страниц, т.к. блоб хранится "древовидно", как индекс (правда не может иметь глубину больше 3). -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Hello, Alexey! Alexey Popov wrote: К сведению, в следующей версии FB ты уже не создашь базу со страницей менее 4К. А лопатой по спине? Кто такие бредовые идеи генерит? У меня мелкие базы которые именна на 1к работают. базы со страницей 1К практически всегда тормозят, и очень хреново ремонтируются (дольше, и больше денег). с 1К FB2 будет работать. Нельзя будет просто создать базу с 1К, и при очередном b/r база пример размер страницы 4к (если было 1-2к). -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Alexey Popov wrote: А лопатой по спине? Кто такие бредовые идеи генерит? Я. У меня мелкие базы которые именна на 1к работают. И нафуя? Даже на 20МБ базе страница в 4К дает увеличение производительности по сравнению с 1К. -- Дмитрий Еманов
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Yakov! Вы пишешь 11 сентября 2006: YH> Большинство raid на материнках (задрипанных и не очень) -- софтовые. Товарищ не понимает... (С) -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ...
Dmitry Yemanov wrote: К сведению, в следующей версии FB ты уже не создашь базу со страницей менее 4К. А лопатой по спине? Кто такие бредовые идеи генерит? У меня мелкие базы которые именна на 1к работают. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ...
>Р-р страницы какой ? 1024, заливал iso на 600Mb. Садо-мазо ? :) Ну почему же. Просто тестирование на предельных углах атаки. :-) Вообще-то у меня лично в заливке даже таких объемов практической потребности не возникало.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: какой бы ни был, программный raid не имеет смысла, потому что сейчас любая самая задрипанная материнская плата имеет встроенную поддержку raid 0 и 1 на аппаратном уровне. Большинство raid на материнках (задрипанных и не очень) -- софтовые. Они ни чем не лучше, чем raid средствами операционки. А порой даже и хуже.
Re: OFF:? Фрагментация файла БД ...
"Boris Loboda" ... > >Р-р страницы какой ? > > 1024, заливал iso на 600Mb. Садо-мазо ? :) > >Сейчас спокойно залил фильм 700МБ. FB2 RC4 > > Ну а как насчет 10 Гиг? Какой размер страницы должен быть? > > > PS макс. теоритический р-р блоба равен примерно > >(page_size - 28) ^ 3 / 16 Т.е. обратную формулу вывести не получается ? :) Ок, специятельно для тебя EXECUTE BLOCK RETURNS (PAG_SIZE INT, MAX_BLOB BIGINT, MAX_BLOBK INT) AS BEGIN PAG_SIZE = 1024; WHILE (PAG_SIZE <= 1024*16) DO BEGIN MAX_BLOB = (PAG_SIZE - 28) * (PAG_SIZE - 28) * PAG_SIZE / 16; MAX_BLOBK = MAX_BLOB / 1024; SUSPEND; PAG_SIZE = PAG_SIZE * 2; END END PAG_SIZE MAX_BLOBMAX_BLOBK 1024 63.489.024 62.001 2048 522.291.200 510.050 40964.236.447.7444.137.156 8192 34.125.258.752 33.325.448 16384 273.939.185.664 267.518.736 MAX_BLOBM и MAX_BLOBG оставляю в качестве упражнения :) > Не знаю что там с теорией, но большие блобы не лезут в базу. Точно не лезут ? :) > >может в движке есть доп. ограничения, но я их сейчас сходу не вижу и > > это > > однозначно не 64К страниц > > Ну проверка на размер по крайней мере срабатывает. Канешна. Но не на 64К страниц -- Хорсун Влад
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
рекомендовать программный raid сейчас не понимаю кому и зачем. чем второе ядро в коре дуо и два канала сата отличаются от встроенного контроллера? -- Булычев Алексей http://www.stella-npf.ru
Re: OFF:? Фрагментация файла БД ...
Boris Loboda wrote: Не знаю что там с теорией, но большие блобы не лезут в базу. На маленькой странице - и не должны. Когда-нибудь вообще снимем лимит на размер блоба, но IMHO пока это не актуально. Нормальные люди не делают размер страницы в 1К, это чревато. К сведению, в следующей версии FB ты уже не создашь базу со страницей менее 4К. -- Дмитрий Еманов
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
дохнет все. при этом у программного raid вероятность сдохнуть во много раз выше, чем у аппаратного. Во сколько? Хотя бы по твоей личной статистике на, полагаю, достаточно обширной клиентской базе. Без хотя бы грубых прикидок в цифрах это спор о личных пристрастиях. скажем так - я не слышал про базы IB/FB на программном raid, и также почти не слышал про умирания контроллеров raid (скорее единичные случаи). Диски в raid дохнут чаще. из моих объектов и опыта аппаратный райд сдохшие: Людиново, - контроллер, диски областная налоговая - контроллер, диски программный райд - сдохшие нет программный райд - успешно работающие: байкальск - горнолыжка волен - горнолыжка РГШ - 5 склонов КЗАЭ КТЗ СААЗ сами аппаратный Сочи, Ривьера давеча сдох диск в конторском серваке - таких уже не выпускают, пошел, прикупил первый попавшийся - и вот оно - работат. утверждения о непригодности программного зеркалирования - в лучшем случае - суеверие, в худшем же - ересь PS реанимировать сервак со сдохшим аппаратным контроллером мне ни разу не удалось (из двух раз) -- Булычев Алексей http://www.stella-npf.ru
Re: OFF:? Фрагментация файла БД ...
Да ? Ровно 64К страниц заливал ? А 64К+1 уже не лезет ? :))) Когда-то что-то такое и было. Только влазило 64k-1, а ровно 64k уже нет. Вот что Дима Еманов писал, когда битие базы правил: ---13.10.2005 ---> На самом деле, так оказалось (PageSize / 4) * (PageSize / 4) * PageSize. ---> Что, впрочем, равно тем же 64М на маленькой странице. ---> Сегодня добавил нормальную проверку на размер. __ Р-р страницы какой ? 1024, заливал iso на 600Mb. Сейчас спокойно залил фильм 700МБ. FB2 RC4 Ну а как насчет 10 Гиг? Какой размер страницы должен быть? PS макс. теоритический р-р блоба равен примерно (page_size - 28) ^ 3 / 16 Не знаю что там с теорией, но большие блобы не лезут в базу. может в движке есть доп. ограничения, но я их сейчас сходу не вижу и это однозначно не 64К страниц Ну проверка на размер по крайней мере срабатывает.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: скажем так - я не слышал про базы IB/FB на программном raid, и также почти не слышал про умирания контроллеров raid (скорее единичные случаи). Диски в raid дохнут чаще. А что диски в RAID дохнут, так для того RAID и придумали, чтоб этого не бояться. Я тоже не слышал про базы IB/FB на программном raid. Но программный RAID нас тоже всегда спасал и спасает. Среди сотни с лишним автоматизированных автовокзалов (пока не имеет отношения к FB, но только ПОКА, скоро все изменится ;-)) за 11 лет невосстановимых падений серверов под Netware 3.12 с программным RAID 1 не было НИ РАЗУ! Один раз убили том своими руками при установке новой системы, да и то "дрова" кривые попались :-) Кстати, именно тогда пытались "поднять" АППАРАТНЫЙ RAID1 на материнке :-)) -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Alexander! Alexander Goldun wrote: Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Аппаратный raid позволяет сделать зеркалирование не дисков целиком, а выбранных разделов? нет. А смысл? Давайте так - я считаю программный raid бессмыслицей, несмотря на письмо Артура Галимова. Допускаю использование программного raid когда контроллера с поддержкой raid нет, и нет денег, и техника старая, и вообще. рекомендовать программный raid сейчас не понимаю кому и зачем. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Re[4]: OFF:? Фрагментация файла БД ...
> Остановились на > Page Size 8192; > DATABASE_CACHE_PAGES 1024; > что-то мне это напоминает :-) Page Size 16384; DATABASE_CACHE_PAGES 512;
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Dmitri Kuzmenko said the following on 09.09.2006 22:00: > дохнет все. при этом у программного raid вероятность сдохнуть во > много раз выше, чем у аппаратного. Возможно для винды это именно так, не знаю. А программный raid в linux ничем не хуже аппаратного, и по надежности - в том числе. -- Oleg
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: какой бы ни был, программный raid не имеет смысла, потому что сейчас любая самая задрипанная материнская плата имеет встроенную поддержку raid 0 и 1 на аппаратном уровне. Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Аппаратный raid позволяет сделать зеркалирование не дисков целиком, а выбранных разделов?
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
ArtGal пишет: Диски в raid дохнут чаще. За 4 года сдохло 4 сказика, IDE и SATA - десятка полтора. Из скольки? А то это похоже на статистику угоняемости. Оказывается, самый угоняемый - ВАЗ чего-то там, хотя угоняют небось единицы машин на сотню. А какая-нибудь редкая марка, которой угнали лишь две штуки, но из всего 3-х имевшихся в стране, попадает вниз рейтинга угонов.
Re: OFF:? Фрагментация файла БД ...
"Boris Loboda" ... > > > > >> >Залей в БД блоб на 10Г > >> > >> Уже разве предел в 64K страниц преодолели? > > > >Какой-такой предел в 64К страниц ? Откуда дровишки ? > > Дровишки добыты посредством собственноручного заливания ISO-образа в блоб. Да ? Ровно 64К страниц заливал ? А 64К+1 уже не лезет ? :))) > --- > Implementation limit exceeded > Maximum BLOB size exceeded > --- > WI-V2.0.0.12724 Firebird 2.0 Release Candidate 4 Р-р страницы какой ? > Ранее вообще база билась от такого заливания, потом как-то Дима Еманов > исправил чтоб оно хоть предельный размер проверяло. Сейчас больше чем > положено не пропускает. Это да, правили в 2-ке такое > Но по нынешним меркам вроде бы лимит поднять надо, > уже XXI век вроде как, гиговые размеры вполне в моде. Сейчас спокойно залил фильм 700МБ. FB2 RC4 -- Хорсун Влад PS макс. теоритический р-р блоба равен примерно (page_size - 28) ^ 3 / 16 может в движке есть доп. ограничения, но я их сейчас сходу не вижу и это однозначно не 64К страниц
Re: OFF:? Фрагментация файла БД ...
Hello, Boris! Boris Loboda wrote: Дровишки добыты посредством собственноручного заливания ISO-образа в блоб. --- Implementation limit exceeded Maximum BLOB size exceeded --- WI-V2.0.0.12724 Firebird 2.0 Release Candidate 4 странно. а размер страницы какой? согласно информации от АК макс. размер блоба может быть 4 гига, в udf - 2 гига. Но размер блоба зависит от размера страницы. где это было написано не помню, но вроде как для 8к страницы 2 гига лимит. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
>Залей в БД блоб на 10Г Уже разве предел в 64K страниц преодолели? Какой-такой предел в 64К страниц ? Откуда дровишки ? Дровишки добыты посредством собственноручного заливания ISO-образа в блоб. --- Implementation limit exceeded Maximum BLOB size exceeded --- WI-V2.0.0.12724 Firebird 2.0 Release Candidate 4 Ранее вообще база билась от такого заливания, потом как-то Дима Еманов исправил чтоб оно хоть предельный размер проверяло. Сейчас больше чем положено не пропускает. Но по нынешним меркам вроде бы лимит поднять надо, уже XXI век вроде как, гиговые размеры вполне в моде.
Re: Re[4]: OFF:? Фрагментация файла БД ...
"Константин" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] O> DATABASE_CACHE_PAGES - подкручивал? сколько? Блин наверное в этом и проблема :( Кто-то прикрутил, может и я, не помню :), до 8192 ... Вот мы довольно долго эксперементировали с этим. Месяца 3 по всякому тестили классик. Остановились на Page Size 8192; DATABASE_CACHE_PAGES 1024; Конечно все это зависит от конкретного железа, кол-ва коннектов и т.д. и т.п. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > скажем так - я не слышал про базы IB/FB на программном raid, Извините, что встреваю. У нас на программном raid (mirror) 18 баз в аптеках. Конечно, надежность программного raid'а во много раз ниже чем аппаратного. Но все таки это лучше чем ничего. Аптеки работают в режиме 24/7, температура около 30, влажность 90-100%, эл. питание - то потухнет, то погаснет (Сочи потому что). Техника старая и дешевая (селероны на древних материнках). На моей памяти с окт. 2002 по наст. время программный raid1 спасал нас не менее 12 раз. > и также почти не слышал про умирания контроллеров raid (скорее > единичные случаи). Совершенно верно За 4 года у нас умер всего один raid контроллер. Даже не умер, а начал время от времени притормаживать. > Диски в raid дохнут чаще. За 4 года сдохло 4 сказика, IDE и SATA - десятка полтора. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Alexander! Alexander Goldun wrote: дохнет все. при этом у программного raid вероятность сдохнуть во много раз выше, чем у аппаратного. Во сколько? Хотя бы по твоей личной статистике на, полагаю, достаточно обширной клиентской базе. Без хотя бы грубых прикидок в цифрах это спор о личных пристрастиях. скажем так - я не слышал про базы IB/FB на программном raid, и также почти не слышал про умирания контроллеров raid (скорее единичные случаи). Диски в raid дохнут чаще. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Константин wrote: Блин наверное в этом и проблема :( Кто-то прикрутил, может и я, не помню :), до 8192 ... На классике? Садюга... -- Regards. Ded.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: дохнет все. при этом у программного raid вероятность сдохнуть во много раз выше, чем у аппаратного. Во сколько? Хотя бы по твоей личной статистике на, полагаю, достаточно обширной клиентской базе. Без хотя бы грубых прикидок в цифрах это спор о личных пристрастиях.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Alexander! Alexander Goldun wrote: Наблюдал я такое разбитое аппаратное корыто: винты целы, а контроллер сдох и с производства давно снят. А уж душещипательных рассказов про подобное наслушался не меньше. Так что песни петь про супер-надежность аппаратных raid по сравнению с софтовыми лучше не надо. Бэкапы рулят. А дохнет все. при этом у программного raid вероятность сдохнуть во много раз выше, чем у аппаратного. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Re[4]: OFF:? Фрагментация файла БД ...
> Бухгалтерия как наоткрывает отчётов бешенных ... > Я их в тредах отдельными потоками считаю ... > Не могу уменьшить - прибьют ... ;) я не говорю про работающие... я говорю про реально ничего не делающие коннекты. (а память-то занята) просто по таймауту отключаются самим приложением, если ничего не происходит достаточно долго.
Re: Re[4]: OFF:? Фрагментация файла БД ...
> Выделенный сервак, правда на дуругом разделе Файловый > архив .. но (вроде?) активно не юзался :( файловый архив тебе тоже не в помощь. и этими фалами тоже, System Cache забивается смотри сам, конечно...
Re[4]: OFF:? Фрагментация файла БД ...
>> DK> 35 мег на 1 процесс - метаданных в базе много? >>Да не очень: ~20 таблиц, ~100 вьюх, ~700 SP O> DATABASE_CACHE_PAGES - подкручивал? сколько? Блин наверное в этом и проблема :( Кто-то прикрутил, может и я, не помню :), до 8192 ... O> 20 гиг база, на 2 гигах памяти... как мне повезло. :) Дык вроде хватало :) O> а DATABASE_CACHE_PAGES - УМЕНЬШИЛ, что бы больше оставалось под SystemCache Попробую ... O> Кроме того, поработал над приложениями, что бы коннектов было минимальное кол-во. O> (у меня тоже Classic). Бухгалтерия как наоткрывает отчётов бешенных ... Я их в тредах отдельными потоками считаю ... Не могу уменьшить - прибьют ... ;) Раньше всё в одном коннекте работало, заставили переделать - захотели чтоб отчётики незаметно считались и не тормозили остальное :( С уважением, Константин Григорьевич. ===
Re: Re[2]: OFF:? Фрагментация файла БД ...
> DK> 35 мег на 1 процесс - метаданных в базе много? >Да не очень: ~20 таблиц, ~100 вьюх, ~700 SP DATABASE_CACHE_PAGES - подкручивал? сколько? System Cache... ..честно - незнаю, как совладать с ним. 20 гиг база, на 2 гигах памяти... как мне повезло. :) Когда на 1 гиг памяти база перелезла на 3 гб, начали ощущаться "легкие тормоза". Не придумал ничего лучшего, чем докупить памяти до 4-6 (где как) а DATABASE_CACHE_PAGES - УМЕНЬШИЛ, что бы больше оставалось под SystemCache Кроме того, поработал над приложениями, что бы коннектов было минимальное кол-во. (у меня тоже Classic).
Re: OFF:? Фрагментация файла БД ...
"Boris Loboda" ... > > >Залей в БД блоб на 10Г > > Уже разве предел в 64K страниц преодолели? Какой-такой предел в 64К страниц ? Откуда дровишки ? -- Хорсун Влад
Re: OFF:? Фрагментация файла БД ...
Залей в БД блоб на 10Г Уже разве предел в 64K страниц преодолели?
Re[2]: OFF:? Фрагментация файла БД ...
DK> мне кажется ключевое слово здесь "Classic". DK> 35 мег на 1 процесс - метаданных в базе много? Да не очень: ~20 таблиц, ~100 вьюх, ~700 SP >> O&O Defag ... :( это по быстрому, сорри детальный DK> я про базы данных У ДРУГИХ ЛЮДЕЙ. 20 гиг - не массовый размер. DK> представь себе удивленное лицо парня, который делает DK> однопользовательскую базу для распространения на хилых компах, DK> когда на очередной чих у него база с 10 мег вдруг увеличивается DK> в 2-4 раза. Дак я понимаю, но можно настроечку какую нить ? DK> Я тебе на что намекаю - дефрагментация тут вообще ни при чем. DK> Это ложный вывод на основе недостатка информации. DK> Может external table такого размера тормозят, или аппликуха твоя, DK> или еще что. DK> Сделай над собой усилие, собери всю окружающую твой случай DK> информацию, и тщательно проверь. я бы предложил проверить: DK> 1. объем памяти занимаемый сервером и приложением при "тормозах". DK> 2. скрость заливки после отключения приложения после появления тормозов DK> 3. скорость заливки после рестарта сервера DK> и т.п. ОК! Буду ловить ... :) DK> А у тебя затормозило на какой то несчастной 20 гиг базе, и ты DK> сломался :-) Есть копать !!! Есть не падать духом !!! Спасибо всем ... Буду думать ... С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Alex Cherednichenko пишет: [Sorry, skipped] DK> Поэтому использование программного raid при наличии DK> аппаратного - #$%#%$#. DK> Ну и извините, по надежности и производительности программный DK> raid вообще не катит. Поддерживаю. На сайтах контор, занимающихся восстановлением данных, можно найти душещипательные рассказы о безвозвратной потере данных на софтовых RAID'ах. Один из примеров со счастливым концом: http://www.datarecovery.ru/lucky_story.htm#L13 Неудачную ты ссылку нашел. Цитата оттуда: === начало цитаты === Данные, хранящиеся в массивах RAID с _аппаратным_ контроллером, очень часто пропадают по причине выхода из строя этого самого контроллера, после сбоя питания, зависания операционной системы и по другим причинам. === конец цитаты === Наблюдал я такое разбитое аппаратное корыто: винты целы, а контроллер сдох и с производства давно снят. А уж душещипательных рассказов про подобное наслушался не меньше. Так что песни петь про супер-надежность аппаратных raid по сравнению с софтовыми лучше не надо. Бэкапы рулят. А если есть возможность, то для файл-сервера гораздо надежнее будет вообще "распределенный RAID-1" - зеркалирование средствами DFS в Win2000-20003. Про производительность не спорю, но если ее хватает, то не вижу противопоказаний против софтового raid-1
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Dmitri! Вы пишешь 09 сентября 2006: [Sorry, skipped] DK> Поэтому использование программного raid при наличии DK> аппаратного - #$%#%$#. DK> Ну и извините, по надежности и производительности программный DK> raid вообще не катит. Поддерживаю. На сайтах контор, занимающихся восстановлением данных, можно найти душещипательные рассказы о безвозвратной потере данных на софтовых RAID'ах. Один из примеров со счастливым концом: http://www.datarecovery.ru/lucky_story.htm#L13 -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Alexander! Alexander Goldun wrote: В любом случае, программный raid - это мазохизм :-) Это почему? raid-5 средствами ОС - может и мазохизм, не знаю. А вот raid 0 и 1 иногда очень удобны для некоторых применений. Впрочем, что я тебе > А RAID 1 средствами ОС - IMHO идеальное решение для недорогих серверов, > например для мелких филиалов. Чем плохо то? Просвети, плиз. какой бы ни был, программный raid не имеет смысла, потому что сейчас любая самая задрипанная материнская плата имеет встроенную поддержку raid 0 и 1 на аппаратном уровне. Поэтому использование программного raid при наличии аппаратного - #$%#%$#. Ну и извините, по надежности и производительности программный raid вообще не катит. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Dmitri Kuzmenko пишет: В любом случае, программный raid - это мазохизм :-) Это почему? raid-5 средствами ОС - может и мазохизм, не знаю. А вот raid 0 и 1 иногда очень удобны для некоторых применений. Впрочем, что я тебе рассказываю? Из твоей же статьи http://www.ibase.ru/devinfo/raid.htm RAID 0 - для монтажа видео - самое то, что надо. Надежность роли не играет, если о ней помнить и хранить бэкапы где надо. А RAID 1 средствами ОС - IMHO идеальное решение для недорогих серверов, например для мелких филиалов. Чем плохо то? Просвети, плиз.
Re: OFF:? Фрагментация файла БД ...
Hello, Константин! Константин wrote: Не спорю, не проверял (ещё), но речь в изначальном посте шла о НОВОЙ БД заливаемой с 0-ля данными ... Ели бы я такую граблю отловил на Restor-e - я б в бооее "конкретных" вырадениях высказывался ;) ... , Наверное :) ... И не я один ... так а заливка данных в пустую базу tpc-r - это что? В одной таблице lineitem 59 миллионов записей. и она занимает 8 гиг из 13-ти после заливки. Заливка длится 1 час 50 минут. (при бэкапе в 20 минут и ресторе 67 минут, без индексов рестор 25 минут). К слову, вот еще данные по дисковой активности при заливке, тебе будет интересно. Понятное дело, что я установил размер страницы 16к и дальше все тесты делал с ним. Хотя рестор на 4к=4к стоит проверить. Кластер NTFS 4K при fw = on 4k page 700kb/сек. при fw=off 4k page 3.5mb/sec при fw = on 8k page 1.35mb/сек при fw=off 8k page 6.2 mb/sec при fw = on 16k page 2.7 mb/сек при fw=off 16k page 7.6mb/sec -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Hello, Константин! Константин wrote: FB вроде и ест не "много" около 500-700 M. при N (~20) коннектах (Classik) но ... мне кажется ключевое слово здесь "Classic". 35 мег на 1 процесс - метаданных в базе много? O&O Defag ... :( это по быстрому, сорри детальный может гляну этой штукой. хотя Diskeeper тоже не брешет, см. мое другое письмо. DK> ага. при размере базы в 10-20 мег? Нельзя. Ты один такой, DK> а других - много. 10-20M Это начальная так сказать "тестовая" БД... я про базы данных У ДРУГИХ ЛЮДЕЙ. 20 гиг - не массовый размер. представь себе удивленное лицо парня, который делает однопользовательскую базу для распространения на хилых компах, когда на очередной чих у него база с 10 мег вдруг увеличивается в 2-4 раза. наверное я в попыхах ошибся с размеерностью :( сорри ... "реальная" сейчас около 20 G! ну 20, и чего. Вот тест tpc-r заливает (dbgen) при коэффициенте 10 (13 гиг база) в одну таблицу 59 миллионов записей, а в другую - 15. И не умирает же он после полутора миллионов! Я тебе на что намекаю - дефрагментация тут вообще ни при чем. Это ложный вывод на основе недостатка информации. Может external table такого размера тормозят, или аппликуха твоя, или еще что. Сделай над собой усилие, собери всю окружающую твой случай информацию, и тщательно проверь. я бы предложил проверить: 1. объем памяти занимаемый сервером и приложением при "тормозах". 2. скрость заливки после отключения приложения после появления тормозов 3. скорость заливки после рестарта сервера и т.п. обхода уже подсказали ... Но!, всё таки гложет мысль, - неужели я один такой ? "Избранный" :)) - Врядли ... PS: Дима, не обижайся, я сказал то что есть ... не надо суетиться и заламывать руки. Вот я уже почитай вторую неделю тупо и методично бэкаплю и ресторю эту долбаную tpc-r базу в 13 гиг. С одного винта на другой, на одном винте, когда темп на одном и на разных винтах, через локалхост. через локальный протокол, через сервисы. С рестором индексов. Без рестора индексов. И т.п. Причем во время всего этого тупо пялюсь на экран в perfmon, записывая по ходу результаты и комментируя, да еще и некоторые вещи приходится перепроверять по 2-3 раза. И ничего, как видишь, живой. А у тебя затормозило на какой то несчастной 20 гиг базе, и ты сломался :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re[2]: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
>> Справка по винде думает иначе DK> тьфу, черт, про динамические диски я забыл. DK> хотя сам недавно при покупке нового винта DK> переделал с динамических на simple. DK> В любом случае, программный raid - это мазохизм :-) :))00 С уважением, Константин Григорьевич. ===
Re[2]: OFF:? Фрагментация файла БД ...
>>4. Restore БД >>5. Дефрагментация диска БД DK> После рестора базы, 13 гиг файл имеет 22 фрагмента. DK> итого примерно по 590 мегабайт на фрагмент. DK> Так что сказки про сильную фрагментацию рассказывать не надо. DK> Причем, фрагменты эти расположены последовательно. DK> т.е. фактически никакой фрагментации на самом деле нет. DK> см. ниже. >> но ведь весь вопрос в том что к концу дня может >> набраться достаточно фрагментов для тормозов (пока теоретически). >> Вопрос был в том что-бы минимизировать КОЛИЧЕСТВО и размер >> фрагментов ... Как либо увеличив выделяемое за 1 раз место на DK> см. выше. при такой "фрагментации" никакой разницы между DK> распределением страниц в файле БД и распределением фрагментов DK> нет. Таблица в базе может быть фрагментирована в 100 и более раз DK> хуже, чем файл БД. DK> С точки зрения доступа к диску ему (контроллеру диска) все едино - что DK> raw disk, что файл. Не спорю, не проверял (ещё), но речь в изначальном посте шла о НОВОЙ БД заливаемой с 0-ля данными ... Ели бы я такую граблю отловил на Restor-e - я б в бооее "конкретных" вырадениях высказывался ;) ... , Наверное :) ... И не я один ... PS: Если я всё таки не прав ... На выходных проведу ещё раз несколько тестов ... Правда после праздника города ;) С уважением, Константин Григорьевич. ===
Re[2]: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
>> Прочитал: >> http://dinamit.vdome.net/index.php/option/content/task/view/id/44/catid/45/Itemid/59 DK> в статье вроде бы все ничего, только DK> брехня про то что Windows NT (?) ПРОГРАММНО поддерживает DK> raid 0, raid 1 и raid 5. Никаких RAID Windows ни в какой DK> версии "не поддерживает". RAID обеспечиваются или программно DK> сторонними средствами, или аппаратно на уровне железа. ? !! Штатными средствами XP - точно поддерживабтся ! Хоть и не использую, но, вроде побовал, - работает !!! С уважением, Константин Григорьевич. ===
Re[2]: OFF:? Фрагментация файла БД ...
>> Update - нет есть только Insert. Коммит после каждых ~100 000 записей >> После 2-3 "лимона" начинаются жуткие тормоза ... DK> см. taskmanager - кто сколько памяти ест - FB, приложение и т.п. DK> сколько RAM на компе? 2G, свободных минимум 512K ... Выделенный сервак, правда на дуругом разделе Файловый архив .. но (вроде?) активно не юзался :( FB вроде и ест не "много" около 500-700 M. при N (~20) коннектах (Classik) но ... >> После танцов с бубном обнаружил что файл БД сильно фрагментирован ... DK> чудеса в решете. И тем не мение :( >> Помотрел КАК дефрагментирован файл БД и прикольнулся :) DK> почему-то у меня такое не наблюдается. чем смотришь? O&O Defag ... :( это по быстрому, сорри детальный анализ, другими средствами не производил :( (не успел ...) >> PS: Может это и офтоп, и виновата как всегда Windows :) DK> разумеется. :) а приручить её можно ? >> Можно ли как-нибуть это обойти, ну хотя-бы сказать FB >> Захватывать кусками по 100 Mb ? DK> ага. при размере базы в 10-20 мег? Нельзя. Ты один такой, DK> а других - много. 10-20M Это начальная так сказать "тестовая" БД... наверное я в попыхах ошибся с размеерностью :( сорри ... "реальная" сейчас около 20 G! И если я один такой - :(. неужели, что-то не верится !) Ладно пока смирюсь ... тем более несколько вариантов обхода уже подсказали ... Но!, всё таки гложет мысль, - неужели я один такой ? "Избранный" :)) - Врядли ... PS: Дима, не обижайся, я сказал то что есть ... С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
Dmitri Kuzmenko wrote: см. выше. при такой "фрагментации" никакой разницы между распределением страниц в файле БД и распределением фрагментов нет. Таблица в базе может быть фрагментирована в 100 и более раз хуже, чем файл БД. Это да. Фрагментация вообще имхо имеет значение только для тупого Select * From Onetable без Order By на свежей базе без версий. Как только начал джойнить-фильтровать-сортировать-группировать, а записи разбежались по страницам - пофиг. А вот расширение файла должно быть операцией сравнительно затратной по логике вещей и иметь возможность управлять размером порции откусывания было бы, пожалуй, полезно. -- Regards. Ded.
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Oleg! Oleg LOA wrote: "Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] брехня про то что Windows NT (?) ПРОГРАММНО поддерживает Справка по винде думает иначе тьфу, черт, про динамические диски я забыл. хотя сам недавно при покупке нового винта переделал с динамических на simple. В любом случае, программный raid - это мазохизм :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Hello, Константин! Константин wrote: 4. Restore БД 5. Дефрагментация диска БД После рестора базы, 13 гиг файл имеет 22 фрагмента. итого примерно по 590 мегабайт на фрагмент. Так что сказки про сильную фрагментацию рассказывать не надо. Причем, фрагменты эти расположены последовательно. т.е. фактически никакой фрагментации на самом деле нет. см. ниже. но ведь весь вопрос в том что к концу дня может набраться достаточно фрагментов для тормозов (пока теоретически). Вопрос был в том что-бы минимизировать КОЛИЧЕСТВО и размер фрагментов ... Как либо увеличив выделяемое за 1 раз место на см. выше. при такой "фрагментации" никакой разницы между распределением страниц в файле БД и распределением фрагментов нет. Таблица в базе может быть фрагментирована в 100 и более раз хуже, чем файл БД. С точки зрения доступа к диску ему (контроллеру диска) все едино - что raw disk, что файл. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
"Dmitri Kuzmenko" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > брехня про то что Windows NT (?) ПРОГРАММНО поддерживает Справка по винде думает иначе Disk Management\How to...\Manage dynamic volumes Manage RAID-5 volumes Create a RAID-5 volume Reconnect the disk and repair the RAID-5 volume Replace a disk region in the RAID-5 volume Reactivate a RAID-5 disk
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Dmitri! Вы пишешь 08 сентября 2006: DK> брехня про то что Windows NT (?) ПРОГРАММНО поддерживает DK> raid 0, raid 1 и raid 5. Никаких RAID Windows ни в какой DK> версии "не поддерживает". RAID обеспечиваются или программно DK> сторонними средствами, или аппаратно на уровне железа. Это не так. http://search.msn.com/results.aspx?q=Windows+NT+Operating+System+Striping+RAID&FORM=QBRE3 -- With best regards, Alex Cherednichenko.
Re: OFF:? Фрагментация файла БД ...
Размер надо увеличивать пропорционально. Например на 10%. -- --- Home Page http://ok.novgorod.net/ap ---
Re: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Hello, Константин! Константин wrote: Прочитал: http://dinamit.vdome.net/index.php/option/content/task/view/id/44/catid/45/Itemid/59 в статье вроде бы все ничего, только брехня про то что Windows NT (?) ПРОГРАММНО поддерживает raid 0, raid 1 и raid 5. Никаких RAID Windows ни в какой версии "не поддерживает". RAID обеспечиваются или программно сторонними средствами, или аппаратно на уровне железа. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Hello, Константин! Константин wrote: А если, чур меня, придётся переходить на режим 24/7 ? А "фоновым" дефрагментаторам я свою БД не доверю, да и сомневаюсь что-бы FB отдал кому нить свой файл на растерзание :) diskeeper 8-9-10 работает отлично, сбоев ни разу, может дефрагментировать файлы in use. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
Hello, Konstantin!
Константин wrote:
2. БД на отдельном разделе (NTFS)
3. На тот раздел вроде ничего больше не прикрученно
ok.
Формачу раздел. Создаю БД. Заливаю данные. Страница БД = Кластеру диска =
4096
ok.
Пправда заливка идёт через внешние файлы с другого раздела + куча проверок.
{do}
Update - нет есть только Insert. Коммит после каждых ~100 000 записей
После 2-3 "лимона" начинаются жуткие тормоза ...
см. taskmanager - кто сколько памяти ест - FB, приложение и т.п.
сколько RAM на компе?
После танцов с бубном обнаружил что файл БД сильно фрагментирован ...
чудеса в решете.
Помотрел КАК дефрагментирован файл БД и прикольнулся :)
1. Фрагменты файла разбросаны по всему диску хаотично :(
(напоминаю кроме БД там ничего нет и диск
свежеформатирован/дефрагментирован)
почему-то у меня такое не наблюдается.
чем смотришь?
2. Каждый фрагмент имеет как минимум 1 кластер пустого
пространства перед следующим !?
PS: Может это и офтоп, и виновата как всегда Windows :)
Но, имхо, такое впечатление что FB запрашивает у системы
(при нехватке страниц) по 1-му кластеру ...
разумеется.
Можно ли как-нибуть это обойти, ну хотя-бы сказать FB
Захватывать кусками по 100 Mb ?
ага. при размере базы в 10-20 мег? Нельзя. Ты один такой,
а других - много.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: OFF:? Фрагментация файла БД ...
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > р-р тоже задать, не вижу вреда\проблем Дык надо делать к релизу тоды :-) >> В смысле пути ничейной страницы :-) > >PAG_allocate который ? Неа, котрый после того как странцы стала пустой с флагом orphan или как его там.
Re: OFF:? Фрагментация файла БД ...
Константин wrote: SST> Ребята, которые работают на Южной Железной Дороге Украины SST> используют InterBase 5 и у них постоянно идёт SST> дефрагментация раздела с базой данных SST> стандартным виндовским дефрагментатором. Никто базу данных не останавливает. SST> Сам видел в 1999 году. Я к ним тогда на работу пытался устроится. Круто !!! Я плакаль ... Не, я так рисковать не хочу :( И правильно. Чего мы с тобой забыли на Южной Железной Дороге Украины? :) -- Regards. Ded.
Re: OFF:? Фрагментация файла БД ...
"Oleg LOA" ... > "Horsun Vlad" ... > >Не вижу большого смысла добавлять такой пар-р. БД должна расти > > относительно > > большими кусками, но смысла в точной настройке р-р этих кусков не вижу. > > Размер БД при СОЗДАНИИ, а не насколькоона будет расти. Ну вот этими кусками и будет расти. Хотя можно и опциональный начальный р-р тоже задать, не вижу вреда\проблем > >В смысле ? Где PIP живёт забыл ? :) > > В смысле пути ничейной страницы :-) PAG_allocate который ? -- Хорсун Влад
Re: OFF:? Фрагментация файла БД ...
"Horsun Vlad" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Не вижу большого смысла добавлять такой пар-р. БД должна расти > относительно > большими кусками, но смысла в точной настройке р-р этих кусков не вижу. Размер БД при СОЗДАНИИ, а не насколькоона будет расти. >В смысле ? Где PIP живёт забыл ? :) В смысле пути ничейной страницы :-)
Re[3]: OFF:? Фрагментация файла БД ...
OL>> Ну 100 ГБ ему хватит я думаю на первое время. С тебя 10 OL>> блобов указанного размера выслать товарищу на e-mail К> >:) Не надо !! ;) Всё нормально, конфисковал у менеджеров приратский видео "Гафрилд2" - заливаю в блоб заодно посмотрю как себя ведёт БД с громадными блобами ;) Публиковать мой ящик и высылать на него swap не наддо ;) PS: Интерестно сколько успею посмотреть пока 4 гига зальёться ? Слава богу начальства нет, народу тоже, завтра день города ... ;) С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
"Oleg LOA" ... > "Ded" ... > >Главное - сюда не выкладывай :) А кстати, отчего Length в Create > > Database велено пользовать только при создании многофайловых баз? > > Давайте лучше ответим на два вопроса. > > 1) Когда добавим это парметр при создании БД Не вижу большого смысла добавлять такой пар-р. БД должна расти относительно большими кусками, но смысла в точной настройке р-р этих кусков не вижу. Выбрать оптимальный алгоритм нужно - например : за один раз расти не менее чем на 64К, не более чем на 128М, в этих пределах - на 10% от текущего объёма. Цифры - почти с потолка :) > 2) Как лучше сейчас раздуть основной файл БД Запастить для начала большим e-mail ящиком :) > P.S. Чё та я туплю, а где у нас список незанятых страинц в файл бд обитает в коде? В смысле ? Где PIP живёт забыл ? :) -- Хорсун Влад
Re[2]: OFF:? Фрагментация файла БД ...
SST> Константин пишет: >> Я согласен это выход если БД например на ночь останавливать >> для B/R то туда же можно прикрутить и дефрагментацию ... SST> Ребята, которые работают на Южной Железной Дороге Украины SST> используют InterBase 5 и у них постоянно идёт SST> дефрагментация раздела с базой данных SST> стандартным виндовским дефрагментатором. Никто базу данных не останавливает. SST> Сам видел в 1999 году. Я к ним тогда на работу пытался устроится. Круто !!! Я плакаль ... Не, я так рисковать не хочу :( С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
"Ded" ... > Главное - сюда не выкладывай :) А кстати, отчего Length в Create Как это - не выкладывай ? А остальный что же - мучаться фрагментированием будут ? :) > Database велено пользовать только при создании многофайловых баз? Насколько я помню\понимаю design - для многофайловых баз длина каждого куска, кроме последнего, прописывается в его header page и создаются файлы для каждого куска, но только с 1-ой страницей - header page. Т.е. этот length не служит для выделения места под соотв. файл в момент создания БД, а только как способ задать р-р каждой части -- Хорсун Влад
Re[2]: OFF:? Фрагментация файла БД ...
OL> "Horsun Vlad" <[EMAIL PROTECTED]> OL> wrote in message news:[EMAIL PROTECTED] >>> Может проще сразу создать БД нужного размера? ;-) >> >>Дык он не знает нужный размер :) OL> Ну 100 ГБ ему хватит я думаю на первое время. С тебя 10 OL> блобов указанного размера выслать товарищу на e-mail >:) Не надо !! ;) С уважением, Константин Григорьевич. ===
Re: OFF:? Фрагментация файла БД ...
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >Главное - сюда не выкладывай :) А кстати, отчего Length в Create > Database велено пользовать только при создании многофайловых баз? Давайте лучше ответим на два вопроса. 1) Когда добавим это парметр при создании БД 2) Как лучше сейчас раздуть основной файл БД P.S. Чё та я туплю, а где у нас список незанятых страинц в файл бд обитает в коде?
Re: OFF:? Фрагментация файла БД ...
Horsun Vlad wrote: "Oleg LOA" ... "Horsun Vlad" ... Может проще сразу создать БД нужного размера? ;-) Дык он не знает нужный размер :) Ну 100 ГБ ему хватит я думаю на первое время. С тебя 10 блобов указанного размера выслать товарищу на e-mail Даже не буду у тебя спрашивать его e-mail ;) Главное - сюда не выкладывай :) А кстати, отчего Length в Create Database велено пользовать только при создании многофайловых баз? -- Regards. Ded.
Re: OFF:? Фрагментация файла БД ...
Константин пишет: Я согласен это выход если БД например на ночь останавливать для B/R то туда же можно прикрутить и дефрагментацию ... Ребята, которые работают на Южной Железной Дороге Украины используют InterBase 5 и у них постоянно идёт дефрагментация раздела с базой данных стандартным виндовским дефрагментатором. Никто базу данных не останавливает. Сам видел в 1999 году. Я к ним тогда на работу пытался устроится.
Re: Re[2]: OFF:? Фрагментация файла БД ... !!!!!!!!!!!!!!!!!!!!!
Привет, Константин! Вы пишешь к Ovchinnikov Vasily 08 сентября 2006: К> ЧТО ДЕЛАТЬ ? КАК ЖИТЬ ? К> Неужели опять FAT с её проблемами ? Нет там никаких проблем (в твоём случае). Кластеры под файл аллокируются тупо линейно. Бинарное дерево NTFS и её журнал тебе нах не нужны. Ресторишь базу как многотомную, кусками по 1-2 Гб. Мог бы порекомендовать RAW-дивайс, но оно есть только под xNIX, а там оно особо и на ухо не упало, ибо нет там таких проблем. -- With best regards, Alex Cherednichenko.
