Тормоза ЕАС

накурил в книжке про СЭКУЛЭ,года два назад скачал,всё прочесть собирался
Size - это размер всех файлов.Space Available - свободное место у них внутри.
объекты в файлах занимают страницы, т.е. области с размером в 8Кб

ща, часа два, и, может вычитаю как увеличить сие значение

POST_SHUTDOWN?? пишет:накурил в книжке про СЭКУЛЭ,года два назад скачал,всё прочесть собирался
Size - это размер всех файлов.Space Available - свободное место у них внутри.
объекты в файлах занимают страницы, т.е. области с размером в 8Кб

Это всё техническая часть, а по факту если они его увеличили тогда ЕАС должен работать быстрее?

Это же ПО от майкрософт...Оно так изначально и создается, чтоб жрало и жрало всё больше ресурсов и тормозило, дабы чтоб  хоть как-то работало терпилам приходится покупать "железо" всё мощнее и мощнее. Это просто бизнес такой. Когда был винпост, база разбухала до гигабайта двух, просто ставили эталонную базу мегабайт 15-30 и всё опять летало тока в путь. А тут...слов нет.

Касательно быстродействия - вы в мониторе ресурсов посмотрите, во что всё упирается. А упирается всё в диск - загрузка всегда 100%, очередь запросов 5..6, время отклика может секунды составлять. А всё потому, что мало того что база огромная (по сравнению с озу), так ещё и всякие почтовые колдунства диск постоянно дёргают. Так что никакими халявными способами типа приведённого списка по "оптимизации" не обойтись - мощные софтовые амбиции почты явно не соответствуют скромным возможностям машинок. Для эксперимента я клонировал одно такое бесконечно тормозное отделение на тестовую машину на SSD - и да,всё залетало. Грузится мгновенно, почтовый мусор(KAV,SCM..& Co) не заметен вообще, даже ЕАС зашевелился. К примеру,кассовую справку за 2 мин создаёт вместо прежних 11. Зашевелился,но не взлетел - теперь всё в CPU упирается,загрузка 100%. Но это уже к светлым головам и золотым рукам разработчиков

"Это всё техническая часть, а по факту если они его увеличили тогда ЕАС должен работать быстрее?"

судя по всему на быстродействие это не влияет. Это, всего лишь, увеличит значение до которого может раздуться база. Ну а чем больше база...…..

"мощные софтовые амбиции почты явно не соответствуют скромным возможностям машинок. "

не надо лишнего пихать, чрезмерно. больно уж всякой дребедени много. На многооконных, в качестве головы, вообще мощные стоят(32 гига оперативы,SSD) но как увиснет порой. только пересчет индексов и помогает, не на долго. Не в технике дело. Техника то не плохая

Ну а если интересует источник периодических нереальных тормозов у ЕАС - погуглите ,что такое касперский KSN (на почте он,разумеется, включён в самом конском варианте), сопоставьте с непрерывным потоком всяких мутных обновлений, и многое станет ясным

POST_SHUTDOWN?? пишет:"Тут по заявке в Наумен дали ответ что в базе не осталось свободного пространства."

не понос, дак золотуха. Чё нить да вылезет. Надо поуточнять вопрос. На нескольких ОПС где 28 Гб, где 30. Чую скоро такие же проблемы начнутся

Да хоть 50 ГБ. Дело не в размере базы.



Ежедневное перестроение индексов с обновлением статистики и нет проблем

с выключенным антивирусом ЕАС работает в 2-3 раза быстрее

POST_SHUTDOWN?? пишет: стоят(32 гига оперативы,SSD)

а файл подкачки используется ?

lehajordan пишет:с выключенным антивирусом ЕАС работает в 2-3 раза быстрее

а вам дают пароль от него? нам нет((

Народ, можете скинуть скрипт для определения процента фрагментации индексов

с выключенным антивирусом ЕАС работает в 2-3 раза быстрее пишет:

Кстати,вопрос может решаться очень просто(казалось бы) - достаточно просто подписывать все эти новые загружаемые файлы (хотя бы сертификатом от russianpost , он же в корневых). К подписанным файлам кошмарыч относится гораздо толерантней , да и безопасность от этого только выросла бы. Вот где поработать бы службам инфбезопасности,а не политики дальше накручивать

"сопоставьте с непрерывным потоком всяких мутных обновлений"

согласен,каждый бит сначала каспер пропустит через себя, просмотрит его внимательно, проверит, ну и так далее

"Ежедневное перестроение индексов с обновлением статистики и нет проблем"

и тут правильно, можно два раза в день))))

"а файл подкачки используется ?"

только что сам не поддуваю, а так на полную. Всяко уже регулировал

Видимо есть какой то нестандартный подход

Нам пообещали дать дополнительно планок оперативки даже, потому шта чота совсем печаль - беда становится...Ну во многих деревнях по 4 гига оперативки ещё, поначалу что примечательно худо-бедно хватало.

Каждое перестроение статистики добавляет обьема базе. Оно старые индексы не удаляет и хранит их. В идеале с начала надо сжать базу а потом перестроить индексы. А в супер идеале после всего этого сделать дефрагметацию.

POST_SHUTDOWN?? пишет:"Ежедневное перестроение индексов с обновлением статистики и нет проблем"

и тут правильно, можно два раза в день))))

В автоматическом режиме через планировщик задач хоть 100 раз в день будет делаться.
Но я сделал у себя один раз в сутки и нет проблем с этим.

"В автоматическом режиме через планировщик задач хоть 100 раз в день будет делаться.
Но я сделал у себя один раз в сутки и нет проблем с этим."

ну не знаю. на 9-ти оконном когда включаем перестроение,дак ОПС часа три раком стоит.Вис неимоверный

POST_SHUTDOWN?? пишет:на 9-ти оконном когда включаем перестроение,дак ОПС часа три раком стоит.Вис неимоверный

хз
тут такая история:
его если раз в пол года запускать (или вообще впервые), то да, будет виснуть и три-четыре часа делаться
если на ежедневной основе отрабатывает, то в три минуты или меньше укладывается и на работу ОПС никак не влияет вообще
такой SQL

"его если раз в пол года запускать (или вообще впервые), то да, будет виснуть и три-четыре часа делаться
если на ежедневной основе отрабатывает, то в три минуты или меньше укладывается"

так то логично.за долгое время и мусора всякого больше накопится.в основном запускается процедура когда уже совсем трындец и путем не работает.Надо прикинут,да может на больших ОПС и сделать. Но с другой стороны. Понабрали подрядчиков ответственных. И как то понизился у меня энтузиазм к рационализаторству. Нас значит на йух,но мы всё равно подумай и поделай.Как то вот....

postpc пишет:

POST_SHUTDOWN?? пишет:"Ежедневное перестроение индексов с обновлением статистики и нет проблем"

и тут правильно, можно два раза в день))))

В автоматическом режиме через планировщик задач хоть 100 раз в день будет делаться.
Но я сделал у себя один раз в сутки и нет проблем с этим.

Оно идея-то конечно не плохая, но что-то московские админы больно рьяно сами стали лезть в тему оптимизации баз и т.п., потому это всё до поры до времени. Это я к тому, что нас просто в итоге "попросят" не лезть в этот их творческий процесс, приготовтесь к тому, что скоро так просто вы доступ даже MS SQL не получите...Хотя я может не совсем правильно последние новости понимаю, но так-то лучше пока в SQL лишний раз не лезть со своими новаторствами.

"приготовтесь к тому, что скоро так просто вы доступ даже MS SQL не получите"

истинно так. В скором времени,скорее всего,доступ к телу(базе) будет на основании доменной учетки пользователя(по подлинности виндос,не SQLкак сейчас сделано во многих ОПС),а вот каким учеткам давать эти права это уже вопрос другой.Думаю желание есть на УФПСы всё возложить,но они запарятся. Потому,возможно,и кому то из оставшихся технарей в почтамтах доступ дадут.