Comments 19
Это самая необычная реклама проекта, которую я когда либо видел
Посыл в том, что нужно заниматься всегда тем, куда тянется душа-чтобы тебе не говорили, чтобы не показывала действительность. Ты сам можешь менять этот мир только своими действиями, а если идти на поводу у других и по протоптанной тропе, то ничего не изменишь.
И если делать с душой даже то, что якобы уже есть, то сделаешь лучше или может даже что-то новое привнесешь в уже казалось бы изученном направлении
И если делать с душой даже то, что якобы уже есть, то сделаешь лучше или может даже что-то новое привнесешь в уже казалось бы изученном направлении
Спасибо бро. Как говорил мой знакомый «от души душевно в душу». Суть идеи — наклепать полезных тулов, которых в работе мне всегда не хватало… и чтобы народ ними тоже пользовался.
Да. Впервые я это прочитал у Р. Фейнмана, в «Вы конечно шутите, мистер Фейнман!», в эпизоде, когда он описывал, как занимался составлением уравнения движения логотипа на донышке тарелки (фрисби?)
Хочешь жить счастливо — играй.
Играй в работу. Занимайся тем, что доставляет тебе удовольствие.
… поначалу было дико.
:-)
Хочешь жить счастливо — играй.
Играй в работу. Занимайся тем, что доставляет тебе удовольствие.
… поначалу было дико.
:-)
Сергей, вопрос по теме.
А зачем дефрагментировать индексы?
:-)
А зачем дефрагментировать индексы?
:-)
Ответ вы и так знаете )))
Мое мнение, индексы нет особого смысла дефрагментировать – лишняя нагрузка на дисковую подсистему и процессор. А вот тот факт, что статистика обновляется за счет ребилда – это штука полезная, поэтому чаще нужно не на индексы смотреть, а на статистику. Плюс чаще всего обслуживание индексов делать нужно для сокращения занимаемого места на диске, а не для борьбы с логической фрагментацией (кучи не в счет, потому что там forwarded records — это проблема насущная).
Мое мнение, индексы нет особого смысла дефрагментировать – лишняя нагрузка на дисковую подсистему и процессор. А вот тот факт, что статистика обновляется за счет ребилда – это штука полезная, поэтому чаще нужно не на индексы смотреть, а на статистику. Плюс чаще всего обслуживание индексов делать нужно для сокращения занимаемого места на диске, а не для борьбы с логической фрагментацией (кучи не в счет, потому что там forwarded records — это проблема насущная).
Вообще, хорошо бы статью написать что-то "Легенды и мифы MSSQLSERVER".
Ну, типа, нужно проводить ежедневную дефрагментацию индексов (помогает увеличить быстродействие, т.к. бонусом идет пересчет статистики по входящим в индекс полям), нужно размещать файлы данных и журнала на разных дисках (бесполезно, если диски на одном виртуальном томе), журнал нужно периодически сжимать (и расстреливать за такое) и т.д.
:-)
Идея хорошая, но у меня сейчас все силы на другое брошены: техническая статья о том как прога работает, публикация на английском и прочее. Чем больше народ будет тулом пользоваться тем больший фитбек я получить смогу и сделать все лучше.
«нужно размещать файлы данных и журнала на разных дисках (бесполезно, если диски на одном виртуальном томе)»-не согласен, прямо сейчас наблюдаю, что эффект есть, но несильный конечно. Т е логическое разбиение даже на одном физическом носителе может дать положительный эффект. Сюда же можно притянуть за уши почему PostgreSQL работает порой быстрее MS SQL, т к PostgreSQL ставят на Linux, а у него файловая система лучше заточена под обработку большого количества файлов. PostgreSQL как раз оперирует с множеством файлов (на каждую таблицу-файл):
infostart.ru/public/962876
по 1С как раз получили сильный выигрыш, по остальным системам пока готовим сравнение (сравниваем постгре 10.5-11.3 и скуль 2016 с последним обновлением, характеристики железа естественно одинаковое)
infostart.ru/public/962876
по 1С как раз получили сильный выигрыш, по остальным системам пока готовим сравнение (сравниваем постгре 10.5-11.3 и скуль 2016 с последним обновлением, характеристики железа естественно одинаковое)
прошу прощения-поторопился с выводами-по тесту Гилева (запускали много раз) как раз получили, что постгре на линуксе с оптимизированными параметрами просела в среднем на 9%, также есть проседания до 9% и по комплексным операциям в 1С.
В итоге после прогонов разных тестов:
в общем получили почти ничью только из-за того, что файловая система лучше на UNIX-системах, чем в Windows, потому постгре и показывает хуже результаты в ОС Windows, чем скуль.
Вообще интересно было бы протестить скуль 2019 (как выйдет) на линуксе и постгре на линуксе, чтобы понять на скоько сильно и как отличаются в производительности две эти СУБД при одинаковой ОС.
Также такие статьи и им подобные не соответствуют действительности по тесту Гилева (возможно были проплачены, либо ради высокого рейтинга для пиара):
infostart.ru/public/962876
Скуль брался 2016 версии девелоперская.
Скорее всего у тех, у кого получился выигрыш в производительности просто неправильно оптимизировали скуль или использовали старые его версии или редакцию урезанную
В итоге после прогонов разных тестов:
в общем получили почти ничью только из-за того, что файловая система лучше на UNIX-системах, чем в Windows, потому постгре и показывает хуже результаты в ОС Windows, чем скуль.
Вообще интересно было бы протестить скуль 2019 (как выйдет) на линуксе и постгре на линуксе, чтобы понять на скоько сильно и как отличаются в производительности две эти СУБД при одинаковой ОС.
Также такие статьи и им подобные не соответствуют действительности по тесту Гилева (возможно были проплачены, либо ради высокого рейтинга для пиара):
infostart.ru/public/962876
Скуль брался 2016 версии девелоперская.
Скорее всего у тех, у кого получился выигрыш в производительности просто неправильно оптимизировали скуль или использовали старые его версии или редакцию урезанную
А на постгрес ставили патч для статистики по темповым таблицам?
Кстати, для дисков под Windows, на которых расположены базы данных (не важно, MSSQLSERVER или postgresql), Вы, конечно же, отключили индексирование файлов средствами Windows, генерацию имен 8.3 и проставление времени последнего доступа? Ну и добавили соответствующие папки в исключения антивируса.
Потому что утверждение что «файловая система лучше на UNIX-системах, чем в Windows» часто базируется на том, что этого не было сделано.
Например, это в обязательном порядке нужно делать, если на таком диске расположена filetable.
Если оставить всё по-дефолту, с filetable становится тяжко работать, если в папке уже 30 тысяч записей (файлов), а если отключить — то затыкается где-то при 200-300 тысячах записей (файлов).
Из недавнего опыта, т.с.
Кстати, для дисков под Windows, на которых расположены базы данных (не важно, MSSQLSERVER или postgresql), Вы, конечно же, отключили индексирование файлов средствами Windows, генерацию имен 8.3 и проставление времени последнего доступа? Ну и добавили соответствующие папки в исключения антивируса.
Потому что утверждение что «файловая система лучше на UNIX-системах, чем в Windows» часто базируется на том, что этого не было сделано.
Например, это в обязательном порядке нужно делать, если на таком диске расположена filetable.
Если оставить всё по-дефолту, с filetable становится тяжко работать, если в папке уже 30 тысяч записей (файлов), а если отключить — то затыкается где-то при 200-300 тысячах записей (файлов).
Из недавнего опыта, т.с.
Сергей, так в итоге с девушкой вместе?
Скули, слоны, дельфины, листы и прочие СУБД приходят и уходят, а счастье любовное оно как правило одно, и то не у многих
Скули, слоны, дельфины, листы и прочие СУБД приходят и уходят, а счастье любовное оно как правило одно, и то не у многих
На это не буду отвечать. Посыл статьи в мотивации к действию и чтобы нужные люди ее прочитали.
Занимательная история.
Sign up to leave a comment.
Копание могил, SQL Server, годы аутсорса и свой первый проект