это ваша задача только вам ответ на этот вопрос известен
С точки зрения реализации - привилегия, это значение переменной 'Роль пользователя', на основе которого будут срабатывать switch case в логике реализации везде, где необходимо разграничнивать права. В некоторых случаях возможно разграничить права прямо на уровне базы данных (например в запрос данных включить проверку роли пользователя, в случае ее отсутствия запрос вернет пустой результат.. это используют кстати когда есть разгранечение прав пользователя не только на функционал но и на объекты базы данных)
Список ролей может быть в бакэнде зашит, если их менять не собираешься (классика - один админ и много пользователей, нет нужды заводить в базе данных отдельные сущности для администратора, тем более зачастую интерфейс у администратора сильно отличается от пользовательского, чуть ли не отдельное веб приложение.
CityCat4, в наших реалиях государство может говорить красивые вещи одной головой а руками делать совсем другие вещи и преследовать совсем иные цели,... мы уже скатываемся в откровенный маразм
Работа с информационным полем это именно умение с ним работать а не помещение ребенка в стерильную песочницу.
Допустим простая ситуация, вам нужно убрать ивент на клик на кнопку,
создаешь кнопку document.createElement(input) (она создается в памяти пока ты ее недобавишь на страницу, собственно сюда можно добавлять потомков, настраивать события и прочее прочее, пока не добавишь их вдокумент, они не активны), проходишь по всем атрибутам кнопки node.attributes и устанавливаешь такие же атрибуты у созданной, затем удаляешь node.remove и добавляешь на ее место свою созданную
В принципе в каких то ситуациях можно наверное не удалять а только скрыть старый элемент, подправив ему значение класса и id (по которым идентифицируют скрипты), так как скопировать события типа onmousemove или другие наверное будет сложно, но попробуй, а самому их прописывать может оказаться трудоемко (скрипты придется анализировать).
какие проблемы? тебе не нужно знать какая там структура, просто циклом пройтись по dom создать по элементно копию в памяти, удалить старый, добавить новый
решение у вас только одно - делаешь как я описал с использованием новых дисков или резервных от текущего рейда, копируешь с shadow copy во время работы, потом еще раз синхронизируешь контент когда есть возможность остановить работу (уже кратковременно, будут скопированы только изменившиеся данные)
вообще то резервный сервер для подобных задач отличная практика
Убирать можно только диски-копии (raid перейдет в состояние не degraded), кстати это вариант выйти из проблемной ситуации - аккуратно извлечь из рейда половину дисков (очень опасная ситуация, можно развалить рейд если ошибетесь), на их основе создать несколько новых рейдов поменьше и переносить данные на них
p.s. настоятельно рекомендую не делать один гигантский рейд массив, лучше несколько маленьких - так конфигурация гибче.
еще рекомендую, лучший шанс, создавать не аппаратный рейд а софтовый, отвяжетесь от вендорлока производителя вашего рейд-контроллера.
хех, выглядит так будто это фейковый антивирус (такие рисуют анимацию проверки и пишут - о обнаружен вирус, купите и мы его вылечим)
Если бы не большая разница 40к и 13к то я бы сказал что это наверное тестирование памяти (антивирус смотрит процессы в памяти и проверяет все подключенные ими библиотеки)
в любой непонятной ситуации ставь скобки ;)
мне лень разбираться, нужно смотреть какой оператор какой приоритет имеет в вашем случае, скорее всего что то не так происходит, если берешь элемент массива void
только если его сделали заранее
ssh это и есть последний шанс
сервер то работает? а то слишком малые шансы что ssh подвис а все остальное работает, перезагрузка обычно самый простой способ решить проблемы (лучше конечно локализовать причину но кто этим будет заниматься у вас)
p.s. причина может быть - проблемы с сетью, там такая же ошибка выпадать должна
Такие лаги выглядят как если бы память машиины уходила в своп, когда вы ее дергаете запросом, эта память из свопа вылезает, как раз несколько секунд тратится
Еще возможно хостер оверселит дисковые подсистемы, т.е. ваш диск не ваш а используется еще клиентами хостера (это нормально, за счет оверселинга vps-ка и дешевле bare metal), т.е. ваши данные улетели из кеша, а диски нагружены другим клиентом, пока все это раскочегарится...
Найти причину можно экспериментами, рекомендую разместить на сайте простенькую страничку-тест, которая при открытии будет засекать время и выводить его в качестве ответа, затем делать что то, снова выводить и так по каждой предполагаемой причине зависания... т.е. последовательно выделить память, прочитать файл, прочитать файл по сети и т.п., делов на 5 -6 строчек, затем открывая ее в разное время со своей машины, смотреть тайминги.
С точки зрения реализации - привилегия, это значение переменной 'Роль пользователя', на основе которого будут срабатывать switch case в логике реализации везде, где необходимо разграничнивать права. В некоторых случаях возможно разграничить права прямо на уровне базы данных (например в запрос данных включить проверку роли пользователя, в случае ее отсутствия запрос вернет пустой результат.. это используют кстати когда есть разгранечение прав пользователя не только на функционал но и на объекты базы данных)