1cv8.1 SQL вариант. (sql и 1с сервер на одном серваке)
памяти 4Gb http://lh6.ggpht.com/-ad3WWTwRqQM/TrJPJCgD1jI/AAAAAAAAAbY/PrzA6ahJOVY/image96129109.jpg
пользователей не больше 20 . Обычно гораздо меньше

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

Описание глюка:
1) Если пользователь сидит в 1с.
И глюк наступил не по его вине.
То наблюдается зависание 1с.
Которую можно вырубить через task manager.

2) Если глюк наступил и пользователь пытается зайти в 1с
Пользователь доходит до выбора базы.
Затем запускает 1c предприятие, либо 1с конфигуратор.
И происходит зависание.
Висит окошко от 1с . И до ввода логина пользователь уже не доходит.
1с можно убить с помощью task manager

3) Если глюк не наступил.
Если вы пытаетесь зайти в конфигуратор.
И по вашей вине наступит глюк.
То вы доходите до выбора базы.
Запускаете 1с конфигуратор.
Доходите до ввода логина.
Вводите его.
И происходит зависание.
Висит окошко от 1с . И до открытия конфигуратора уже не доходит
1с можно убить с помощью task manager

4) Если глюк уже наступил
И вы пытаетесь зайти в конфигуратор на сервере sql
То вы видите такое сообщение
http://lh6.ggpht.com/-pIuko8vgKns/TrE0vU97gQI/AAAAAAAAAao/DUPC1OzJbvg/image23826453.jpg

5) http://lh3.ggpht.com/-P73b-3t5bDg/TrFUA7M-JjI/AAAAAAAAAbI/5z8g6j-e4qo/image31838343.jpg
На этом скриншоте глюк уже наступил.
Во время глюка процесс rphost.exe грузит процессор примерно 12% +- 2%
(если глюка нету то загрузка процессора 0 - 7 %)
также на этом скрине видна консоль "серверы 1с предприятия"

6) Если во время глюка убить процесс rphost.exe с помощью task manager то глюк исчезает.
процесс rphost.exe после смерти через несколько секунд оживает.

7)Год ничего подобного не видел. Проблема появилась ровно вчера.
За день до глючных событий на 1с пытались выполнить некую операцию.
Из за которой 1с попыталась создать темповые файлы огромнейшего размера (30ГБ).
И израсходовала все свободное пространство диска C:
Сервер был перезагружен. Темповые файлы были удалены.
Пол дня все работало нормально. На следующий день пару часов с утра все работало нормально.
И затем стали наблюдаться глюки.
Глюк наблюдается при доступе к кофигуратору люббой восьмерочной базы (основная, куча тестовых)

Вначале подумал - стихи какие-то)))

~12% при 8 поцессорах(ядрах)

~=100% одного ядра.

что говорят технологический журнал и мс скл профайлер.

может превышен макс размер файла в Config

смотрел мс скл профайлер - но ничего в нем не разобрался
а что такое  технологический журнал не знаю

вот мой вопрос обновленная версия

1cv8.1 SQL вариант. (sql и 1с сервер на одном серваке)
памяти 4Gb http://lh6.ggpht.com/-ad3WWTwRqQM/TrJPJCgD1jI/AAAAAAAAAbY/PrzA6ahJOVY/image96129109.jpg
пользователей не больше 20 . Обычно гораздо меньше

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

Описание глюка:
1) Если пользователь сидит в 1с.
И глюк наступил не по его вине.
То наблюдается зависание 1с.
Которую можно вырубить через task manager.

2) Если глюк наступил и пользователь пытается зайти в 1с
Пользователь доходит до выбора базы.
Затем запускает 1c предприятие, либо 1с конфигуратор.
И происходит зависание.
Висит окошко от 1с . И до ввода логина пользователь уже не доходит.
1с можно убить с помощью task manager

3) Если глюк не наступил.
Если вы пытаетесь зайти в конфигуратор.
И по вашей вине наступит глюк.
То вы доходите до выбора базы.
Запускаете 1с конфигуратор.
Доходите до ввода логина.
Вводите его.
И происходит зависание.
Висит окошко от 1с . И до открытия конфигуратора уже не доходит
1с можно убить с помощью task manager

4) Если глюк уже наступил
И вы пытаетесь зайти в конфигуратор на сервере sql
То вы видите такое сообщение
http://lh6.ggpht.com/-pIuko8vgKns/TrE0vU97gQI/AAAAAAAAAao/DUPC1OzJbvg/image23826453.jpg

5) http://lh3.ggpht.com/-P73b-3t5bDg/TrFUA7M-JjI/AAAAAAAAAbI/5z8g6j-e4qo/image31838343.jpg
На этом скриншоте глюк уже наступил.
Во время глюка процесс rphost.exe грузит процессор примерно 12% +- 2%
(если глюка нету то загрузка процессора 0 - 7 %)
также на этом скрине видна консоль "серверы 1с предприятия"

6) Если во время глюка убить процесс rphost.exe с помощью task manager то глюк исчезает.
процесс rphost.exe после смерти через несколько секунд оживает.

7)Год ничего подобного не видел. Проблема появилась ровно вчера.
За день до глючных событий на 1с пытались выполнить некую операцию.
Из за которой 1с попыталась создать темповые файлы огромнейшего размера (30ГБ).
И израсходовала все свободное пространство диска C:
Сервер был перезагружен. Темповые файлы были удалены.
Пол дня все работало нормально. На следующий день пару часов с утра все работало нормально.
И затем стали наблюдаться глюки.
Глюк наблюдается при доступе к кофигуратору люббой восьмерочной базы (основная, куча тестовых)
Сомневаюсь что проблема в конфе. Т.к. глюк наблюдается при доступе к конфигуратору любой восьмерочной базе. Даже к тестовым. К которым уже давно не лезли.

http://lh5.ggpht.com/-psGJRaEjgm4/TrJmHpKUXWI/AAAAAAAAAbo/Y6URU3qBnM4/image102005781.jpg
сдесь глюк наступил.

360i мне писал такой ответ.
1 - 03.11.11 - 17:04
   
Все стандартно. Кэш почистить, платформу переустановить, попробовать на другой машине. Судя по всему по какой-то причине у вас возникает зацикливание при открытии конфигуратора и зависание процесса => подключиться к конфигуратору второй раз не получается. Т.к. проблема возникает в различных базах, то дело, скорее всего не в них, а в платформе или скуле.

буду щя по порядку пробовать чего нить.
Для начала разбираюсь как почистить на сервере кешь.

Гипотеза.
Одна и та же база данных SQL сервера зарегистрирована в кластере 1С как разные информационные базы 1С, либо в другом кластере 1С. Проверьте.

не знаю как это проверить. Буду гуглить о том как это проверить. Если не сложно поясните как проверить вашу гипотезу. Это сэкономит мне время.

Да просто посмотреть в свойства всех зарегистрированных информационных баз в кластере 1С (на картинке видно: RAMTEXV8, v8, kgtestv8, kgtestv8a, kgtestv8b)(если у вас их не один кластер, то на каждом), там прописывается имя сервера баз данных и имя базы данных.

раскажите по-подробней про
"на 1с пытались выполнить некую операцию..."

Хотя врядли моя гипотеза подтвердится, при такой регистрации скорее будет обратный эффект.

Пытались выполнить обработку  "Универсальный журнал документов" (по описанию эта обработка формирует журнал всех всех документов восьмерки. Из за этого восьмерка создала огромные темповый файл . Забила подчистую диск C: . И никто не смог войти в восьмерку пока я не перезагрузил сервер. И не расчистил место.

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

чета даже не знаю в какую сторону рыть. Кроме как переставлять скл и 1с сервак

Up

(15)
переставили ?

пока ничего не переустанавливал.  Боюсь нажить еще больше проблем чем есть.
Я заметил. Что глюк любит появляется в определенное время.
Сейчас пытаюсь отыскать закономерность появления глюка

Регламентные задания крутятся?

Регламентные заданий точно нету