Эта проблема началась примерно через две минуты после того, как первому клиенту был предоставлен полный доступ к первому компьютеру, и с тех пор он не исчез. Каждый раз, когда кто-то, чьи приоритеты - это быстро выполнять работу, ориентированную на бизнес, он будет неаккуратен и облажается для всех. Вот как все работает, потому что правильный дизайн и реализация сложнее, чем дешевые хаки. Вы не собираетесь решать эту проблему, все, что вы можете сделать, это выяснить, как сделать так, чтобы клиенту было легче работать с вами, чем с вами. Если вы все сделаете правильно, это будет выглядеть как отличный сервис, а не нытье.
Прежде всего, сторона базы данных. Теперь в PostgreSQL есть способ управления ресурсами запросов. Основная сложность заключается в том, что такие инструменты, как «nice», контролируют использование ЦП, но если база данных не помещается в ОЗУ, вполне возможно, что использование ввода-вывода убьет вас. См. сообщение для разработчика с кратким изложением проблем здесь.
Теперь, если на самом деле это процессор, который прожигают клиенты, вы можете использовать два метода для улучшения этой ситуации:
- Установите функцию C, которая изменяет приоритет процесса ( пример 1 , пример 2 ) и убедитесь, что каждый раз, когда они запускают что-то, он вызывается первым (возможно, поместите это в свою конфигурацию psql). файл, есть другие способы).
- Напишите скрипт, который ищет процессы postmaster, порожденные их идентификатором пользователя, и назначайте их, заставляя его часто запускаться в cron или в качестве демона.
Похоже, ваша проблема не в конкретных процессах запросов, которые они выполняют, а в других модификациях, которые они вносят в более крупную структуру. Есть только один способ справиться с этим: вы должны обращаться с клиентом так, как будто он злоумышленник, и использовать подходы этой части поля компьютерной безопасности, чтобы определить, когда они что-то напутали. Шутки в сторону! Установите на сервере систему обнаружения вторжений, такую как Tripwire (есть лучшие инструменты, это просто классический пример), и пусть она предупредит вас, когда они касаются чего-либо. Новый файл 0777? Должен выпрыгнуть прямо из правильного отчета IDS.
На стороне базы данных вы не можете непосредственно обнаружить, что база данных была изменена с пользой. Вы должны делать pg_dump схемы каждый день в файл ( pg_dumpall -g и pg_dump -s , затем сравнивать его с последним, который вы доставили, и снова предупреждать вас об изменении Если вам это удастся, контакт с клиентом превратится в «мы заметили, что вы изменились на сервере ... что вы пытаетесь сделать с этим?», Что заставляет вас выглядеть так, как будто вы действительно обращаете внимание для них. Это может превратиться в возможность продажи, и они могут перестать возиться с вещами, просто зная, что вы поймаете это немедленно.
Другая вещь, которую вы должны начать делать немедленно, это установить как можно больше программного обеспечения для контроля версий на каждую клиентскую коробку. Вы должны иметь возможность войти в каждую систему, запустить соответствующий инструмент status / diff для установки и посмотреть, что изменилось. Получайте это по почте вам тоже регулярно. Опять же, это работает лучше всего, если в сочетании с чем-то, что дамп схемы в качестве компонента для того, что она управляет. Недостаточно людей используют серьезные подходы к управлению версиями кода, который живет в базе данных.
Это основной набор технических подходов, полезных здесь. Остальное, что у вас есть, - это классическая консалтинговая проблема управления клиентом, которая гораздо больше связана с проблемами людей, чем с компьютером. Ободрись, может быть и хуже - FSM поможет тебе, если ты предоставишь им доступ ODBC, и они обнаружат, что могут писать свои собственные запросы в Access или что-то простое.