Показать сообщение отдельно
Старый 01.07.2011, 16:35   #16  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Link Посмотреть сообщение
Похоже что на MSSQL все выглядит гораздо лучше, без оптимизаций. Постсинхронизация проходит за 6 часов
Это, видимо, без фиговой тучи скриптов обновления базы 3.0 -> 4.0.
Цитата:
Сообщение от Link Посмотреть сообщение
правда на 2008 сервере под VMWare съедает всю доступную память - 15 ГБ.
Настройкой СУБД занимался не я, так что тут вряд ли чем помогу. На оракловом сервере, про который я писал, что он ушел в своп, памяти было 48 Гб
Цитата:
Сообщение от Link Посмотреть сообщение
Пробовал экспортировать в сиквел процесс синхронизации, как указанно в мануале, это может дать улучшение производительности при параллельном запуске на нескольких клиентах.
В моем случае ощутимо ускориться удалось еще за счет того, что пакетный сервер был настроен на гораздо большее число потоков, нежели штатные 8: не все, конечно, но часть скриптов очень хорошо распараллеливается, а основная нагрузка все равно приходится на СУБД, поэтому при настройке имеет смысл ориентироваться на число ядер сервера БД, а не AOS.
Цитата:
Сообщение от Link Посмотреть сообщение
Интересно, вы данные через кубы проверяли. У меня простой джоб все в ексель выкладывает. В чем было преимущество делать через кубы?
В транзакционных таблицах - десятки миллионов записей, Excel подавится. К тому же отделом отчетности, который "ворочает кубы", были заранее написаны соотв. скрипты, и было бы глупо отказываться от удачной возможности переложить на них часть работы по выверке данных
Цитата:
Сообщение от Link Посмотреть сообщение
А мультисайт сразу активировали?
Нет, не сразу. Вообще, первый где-то месяц-полтора было не до мультисайта