Сообщение Re[6]: MS SQL Server для моделирования и научных расчётов от 17.01.2018 13:49
Изменено 17.01.2018 13:56 AlexGin
Re[6]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительности для систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если поток расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две-три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в БД не будет являться наиболее низкопроизводительным звеном.
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительности для систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если поток расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две-три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в БД не будет являться наиболее низкопроизводительным звеном.
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.
Re[6]: MS SQL Server для моделирования и научных расчётов
Здравствуйте, capgreen, Вы писали:
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительности для систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если поток (потоки) расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две-три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в БД не будет являться наиболее низкопроизводительным звеном.
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.
C>Обрезание лога транзакций может привести к падению производительности, поскольку увеличение размера файла транзакций или файла данных относительно медленное мероприятие.
C>Для увеличения производительности полезнее поддерживать размер файлов таким, что бы его увеличение требовалось пореже. Оптимальный вариант — заранее обеспечить в файлах наличие свободного места, что бы серверу не пришлось их наращивать в процессе обработки данных.
Здесь всё дело в том, что "бутылочное горлышко" по производительности для систем расчёта моделей —
не в подсистеме сохранения данных через СУБД (в т.ч. и через MS SQL Server).
Так, например, если поток (потоки) расчета значений модели выдаёт нам результаты очередного шага моделирования каждые две-три секунды,
а вот поток записи данных в БД сохранит эти значения не за 100 ms, а за 200-250 ms — то при этом всё равно,
скорость сохранения данных в БД не будет являться наиболее низкопроизводительным звеном.
Но, тем не менее — спасибо, уважаемый capgreen, буду знать что данный вопрос может всплыть,
если что-либо кардинально изменится в самом ядре моделирования.