 Автор |
Сообщение |
Genbor
Крокодил Гена
 Предупреждений : 1
|
|
Я человек, лишь поверхностно знакомый с принципами работы серверов sql (речь здесь про сервер от майков) и 1с, и поэтому не могу понять одной простой вещи.
По работе частенько бывает так, что у клиентов база становится слишком толстой и дтшник, представленный нам для работы, не разворачивается в файловом варианте. И приходится запускать службы сабжа.
Если буквально недавно база, еще раскрывающаяся в файловом варианте, летала, то стоит ее перенести на рельсы sql она начинает тупить со страшной силой, а сами службы серверов отжирать кучу памяти и процессорной мощности (но не все доступные ресурсы съедают! а база все равно тупит).
Чем эти гребаные сервера занимаются таким постоянно, что требуют таких мощностей? Серверы локальные, работаю на них только я и только с одной базой 1С. И в принципе только с базами 1С. При установке sql никаких дополнительных примочек не ставлю - только голое ядро.
Можно что-то делать, чтобы они ерундой не занимались? |
|
 |
|
 |
ATX555
Гуру
 |
|
| Genbor писал(а): |
| Чем эти гребаные сервера занимаются таким постоянно, что требуют таких мощностей? |
Сужу по MySQL - там файл самой базы (а их может быть десятки разных), индексный файл (иногда такого-же объёма), текущие данные и промежуточные - и это всё сервер как-то пытается сравнить-сохранить. 
В результате куча оперативы отъедено и куча операций записи на диск при этом... 
Т.е. сервер на диск записывает, но из памяти выкидывает не сразу.
Понятно - главное сохранность данных, НО!
При этом малейшее нештатное выключени/зависание/сбой может привести к порче основоного файла. 
Как так-то? 
Сегодня с утра пару часов удалённо возился с восстановлением на одной точке штатными средствами.
Ещё особенность: после восстановления баз или обновления их структуры при значительных объёмах начинают сильно тупить запросы на обработку (я уж и трафик по сети проверял и загрузку проца...) без видимых причин.
Скорее - это особенность организации структуры или запросов, но после оптимизации баз (штатными средствами MySQL) - тупизна проходит (остаются аппаратные ограничения), при этом объём файлов баз остаётся прежним.
Тоже считал, что БД придумали для оптимальной быстрой работы и без сбоев...  |
|
| |
|
|
ATX555
Гуру
|
|
| Genbor писал(а): |
Серверы локальные, работаю на них только я и только с одной базой 1С.
И в принципе только с базами 1С. |
Запросы по сети идут?
Тогда первым деллом проверить сетевой трафик - не тянет ли софт сначала всю базу, чтоб обработать запрос (как раз сетевые версии 1С должны быть без этого недостатка!).
В несетевой лучшим решением было - доступ по RDP - тогда обработка шла на удалённой машине (типа сервер) и можно было оптимизировать-улучшать только его скоростные данные, а на рабочую выдавался уже готовый результат!  |
|
| |
|
|
Genbor
Крокодил Гена
Предупреждений : 1
|
|
| ATX555 писал(а): |
| Запросы по сети идут? |
 а причем тут сеть, если вся связка "сервер sql-сервер1с-база данных-клиент 1С" находятся на одном и том же компьютере? Да и нет сервера, на который можно было бы "расчеты" скинуть... |
|
| |
|
|
ProFfeSsoRr
Гуру
 |
|
| Цитата: |
Сужу по MySQL ...
Как так-то? |
Видимо и mysql старый? Не возись с ним, юзай postgres... и возись с ним 
| Цитата: |
При установке sql никаких дополнительных примочек не ставлю - только голое ядро.
Можно что-то делать, чтобы они ерундой не занимались? |
Настраивать. В БД много настроек, потому что у всех разные данные, разные запросы. разные объемы.
| Цитата: |
Тоже считал, что БД придумали для оптимальной быстрой работы и без сбоев |
так и есть. Но у всех свои особенности + "из коробки" оно всё настроено... да непонятно на что, как "средний человек" - такого не существует. |
|
| |
|
|
Plaguer
Эксперт
 |
|
Попробуйте сделать задачи обслуживания БД по расписанию:
https://its.1c.ru/db/metod8dev/content/5837/hdoc
По своему опыту скажу что результат того стоит: если без них открытие БД в клиенте SSMS (даже системных) после пары мес. аптайма начинает выполняться по несколько (десятков) минут, то после выполнения рекомендаций из статьи - мгновенно.
Так же на производительность MS SQL могут очень сильно влиять снапшоты VMware ESXi - чем их меньше тем лучше. |
|
| |
|
|
ProFfeSsoRr
Гуру
|
|
| Цитата: |
Так же на производительность MS SQL могут очень сильно влиять снапшоты VMware ESXi - чем их меньше тем лучше. |
зачем вообще снэпшоты гипервизора для SQL? С неё бекапы и так нормально родными средствами снимаются (а вот снэпшотом нет, там ж будет много вопросов по журналам потом). |
|
| |
|
|
Genbor
Крокодил Гена
Предупреждений : 1
|
|
| Plaguer писал(а): |
| пары мес. аптайма |
Вы о чем? Какие аптаймы, какие снапшоты? Все работает на обычном ноутбуке, который в начале рабочего дня включается, а в конце - выключается.
Еще раз - у всей этой свистопляски одна единственная цель - просмотр базы данных клиента, которую из-за размеров нельзя развернуть в обычном (файловом) варианте. |
|
| |
|
|
Richard Ferlow
Гуру
 Предупреждений : 2
|
|
Genbor
Я так чисто...поспрашивать да подумать вместе)
А насколько большая база файловая и что происходит при попытке открыть? |
|
| |
|
|
ProFfeSsoRr
Гуру
|
|
| Цитата: |
у всей этой свистопляски одна единственная цель - просмотр базы данных клиента, которую из-за размеров нельзя развернуть в обычном (файловом) варианте. |
почитай, че советуют 1сники по тюнингу ms sql, общие советы, и попробуй их применить у себя. Если прям просо просмотр - повыключай всякие журналы, все, что с надежностью связано. |
|
| |
|
|
Genbor
Крокодил Гена
Предупреждений : 1
|
|
Richard Ferlow
Да базе в принципе не обязательно быть большой самой по себе. Вот, к примеру, база того клиента, про которого я в первом посте писал и который буквально на моих глазах перестал в файловом варианте разворачиваться, весит 30 гигов.
Главное же не сколько база весит, а нет ли в ее составе таблиц "толще" 4 гигов...
А так базы и 100, и 500 гигов бывали. Без учета журналов, конечно.
| Richard Ferlow писал(а): |
| что происходит при попытке открыть? |
Она просто из дтшника не разворачивается (бэкап файл 1с *.dt). Развертка заканчивается ошибкой.
А вот что происходит когда база в рабочем режиме отжирается и перестает открываться - с таким не сталкивался. Почти все те, у кого база принимает более-менее серьезные размеры, на файловых версиях баз не сидят.
ProFfeSsoRr
Да сижу, покуриваю мануалы. Почти нихрена непонятно за что каждый конкретный параметр отвечает... Выключишь какую-нибудь шляпу и все рухнет к чертям.
Думал мне тут скажут какую-нибудь волшебную опцию, для моих нужд подходящую. Ну не должен, имхо, сервер, от которого ничего кроме просмотра не требуют жрать столько ресурсов (понятно, речь про время, когда база просто открытая висит). |
|
| |
|
|
ProFfeSsoRr
Гуру
|
|
| Цитата: |
Выключишь какую-нибудь шляпу и все рухнет к чертям |
ну ты можешь посмотреть параметры на надежность и настроить их наоборот. Потому что чем надежнее - тем медленнее, и тем подробнее журнал (а это - место).
Ну или как вариант заюзать 1с с постгресом, он из коробки настроен на слабые компы, куда десктоп вполне вписывается. Но я не в курсе, насколько 1С хуже/не хуже работает с постгрёй сейчас. |
|
| |
|
|
|
Аватары: Вкл|Выкл ЮзерИнфо: Вкл|Выкл Подписи: Вкл|Выкл
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете вкладывать файлы
Вы можете скачивать файлы
|
|
