Busla
21-12-2007, 12:57
Если серьезно - учите матчасть.
Могу привести два аргумента, теоретический и практический:
1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется.
Потоки делят память внутри процесса.
Идеальный случай:
- у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память.
- один файл данных обслуживает один процесс кэширования операций чтения/записи.
- Файлов много, процессов кеширования тоже.
Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш.
А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы.
Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах. »Матчасть я, как раз, знаю, спасибо:
1) ключ 3gb файла boot.ini позволяет перераспредилить адресное пространство, и пользовательским процессам будет отведено до 3Гб
2) памяти у нас всё же меньше чем объём данных, и для чтения-записи какой-то части файла его ОС целиком в память не грузит
3) ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет".
4) У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно.
Могу привести два аргумента, теоретический и практический:
1) В 32х битной системе процессу больше двух гигабайт памяти не выделяется.
Потоки делят память внутри процесса.
Идеальный случай:
- у вас много памяти, по крайней мере достаточно для безпроблемного кеширования всего и вся, или размер данных не велик и полностью влезает в память.
- один файл данных обслуживает один процесс кэширования операций чтения/записи.
- Файлов много, процессов кеширования тоже.
Так вот, дорогой друг, при размере файла данных более 2 гигабайт, даже при наличии свободной памяти, один процесc не сможет обслужить файл данных, дабы тот целиком влез в кэш.
А при не равном соотношении количестве процессов - файлов это уже конкуренция за ресурсы.
Естественно на это имеет смысл обращать внимание лишь в высоконагруженных системах. »Матчасть я, как раз, знаю, спасибо:
1) ключ 3gb файла boot.ini позволяет перераспредилить адресное пространство, и пользовательским процессам будет отведено до 3Гб
2) памяти у нас всё же меньше чем объём данных, и для чтения-записи какой-то части файла его ОС целиком в память не грузит
3) ОС работает с дисковой системой не на уровне байтов, а на уровне секторов (512 байт); кластеров (как правило больше секторов); SQL Server на уровне - страниц (8Кб) и групп страниц (extent - 64Кб). Соответственно и чтение-запись осуществляется блоками по 8-64 Кб, а не массивами "сколько в память влезет".
4) У нас речь и о величине прироста файла или об абсолютном размере файла? Прирост я как раз рекомендовал делать меньше 2Гб. А разбивать БД на множество мелких файлов в большинстве случаев неэффективно.