Postgresql ошибка нехватка памяти
Конфигурация УНФ при закрытии месяца долго грузится и выдает ошибку не хватает памяти, 1с сервер, potgresql, база не типовая.
в файловом варианте все работает. Что где подкрутить?
(0) сколько памяти на сервере и какие сейчас параметры?
max_connections
shared_buffers
effective_cache_size
maintenance_work_mem
wal_buffers
work_mem
(0) таки не хватает постгри или 1С-серверу или у вас всё на 1 сервере?
Ограничения по памяти на 1 меня сколько?
ни версии платформы 1С и ее разрадности, ни версии УНФ, ни версии постгри, ни версии ОСи - ничего! И кто-то должен оп и чего-то насоветовать.
Ну установите самый последний из существующих, так в нем обновленные уже готовые какие-то настройки будут
в настройках сервера 1с, там где локальный кластер, вызываешь свойства правой кнопкой мышью и если в поле допустимый объем памяти стоит вместо нуля какое то значение в кб то увелич его
Ошибка, грузит около 20 мин, выдает ошибку недостаточно памяти. как понять какой именно памяти ему не хватает?
при этом на жестком диске до ошибки сжирает почти 3гб
Вангую - памяти не хватает серверу предприятия. Если бы памяти было мало СУБД, то в тексте ошибки было-бы что-то указывающее на Postgres. Что-то типа ошибка SQL
(8) в диспетчере на момент перед самой ошибкой кто сжирает памяти много и сразу после ошибки ее высвобождает?
(8) На момент возникновения ошибки в логи PostgreSQL что пишется? Что-нибудь вроде "out of memory" или "Недостаточно памяти для получения результата запроса к базе данных"?
(17) не все, а платформа на сервере. На клиенте может и 32 стоять вполне себе успешно. Ну в режиме толстого клиента пробуй запустить.
(17) просто сжирание на локальном клиенте временного файла до 3 Гб как бы намекает на предел в памяти, который давно существует в майкрософтовых 32бита процессах - 3 ГБ с копейками. Какие-то особенности системы. В теории:
2 ГБ - знаковое целое int.
4 ГБ - беззнаковое целое int
внутренние особенности решения на винде 4 ГБ не позволяют, а только 3 ГБ
(20) Ну вот и еще одну техническую подробность удалось вытащить клещами.
Вообще-то в терминале можно поставить ограничение
А с локальных компов доступ к серверу в принципе возможен? С клиента без использования терминала что выдает? Просто по РДП без терминала на самом сервере с его же платформой.
На всякий случай, выше указывалось проверить сколько памяти задано в настройках агента сервера 1С на каждый рабочий процесс. Вот на это тоже можно посмотреть. Но эта настройка тогда будет давать такую же ошибку при работе с сервером в клиенте с локального компа, без терминала.
но ошибка по рдп
Поменял еще раз параметры postgre перечитал конфу перезагрузил службы. Пока грузит ошибку не выдает. но база растет как на дрожжах. уже на 1гб выросла.
такими темпами каждое закрытие месяца по 2гб не очень хорошо
(22) по росту базы ничего не скажу
Если бы проблема была "на стороне сервера", а не клиента, то при любом способе подключения клиентского было бы одинаковая проблема.
Т.е. видно же что все уперлось в RDP
(24) И что постгри самовольничает со своими параметрами ЗАПУСКА, когда устанавливается клиентское соединение из под разных клиентов?
(24) ну засунь базу на РДП в файловом режиме и протести ее еще и таким способом. Отработает - значит в РДП точно никаких проблем.
я уже писал что в файловом варианте отрабатывает без проблем.
в общем как писал выше в постгре добавил еще чуть чуть. до предельно допустимого исходя из параметров пк. все отлично теперь. без ошибок отрабатывает. но мне не нравится что база выросла на 1 гб.
нормально ли такой рост базы при закрытии одного месяца? если нет, подскажите куда смотреть, что поменять?
(27) vacuum full(и заодно analyze)выполни после закрытия месяца, посмотри на сколько уменьшится размер.
подскажите, что еще может поменять надо? 1 месяц закрылся и все, снова ошибка. и как оказалось сама база то растет не на много. примерно на 200мб, у самого жесткого диска в момент включения операции жрется память, а где не могу найти. Сейчас включил операцию, минут 30 грузилось и выдало снова ошибку "Недостаточно памяти для получения результата запроса к базе данных"
и за эти 30 мин на жестком диске уменьшилось 3гб
есть, кто разбирается в postgre?
что нужно изменить?
через 20 мин после начала процедуры, оперативка подскакивает на 100% и вылетает ошибка, хотя при этом нигде в conf я не выставлял максимальное значение оперативки
Я написал для дельного совета. если не знаешь не пиши.
купить сервер, купить оперативку и прочий подобный бред который и так понятен не надо тут флудить.
Сервер куплен в январе 2018. эти подробности помогут? нет
поэтому maxile считаю что ты флудишь.
Недавно нас по ночам стали будить алерты: на диске не хватает места. Мы быстро разобрались, что проблема в ETL-задачах.
ETL-задача выполнялась в таблице, где хранятся двоичные записи, дампы. Каждую ночь эта задача должна была удалять повторяющиеся дампы и освобождать место.
Для поиска повторяющихся дампов мы использовали этот запрос:
Запрос объединяет одинаковые дампы по BLOB-полю. С помощью функции окна мы получаем идентификатор первого появления каждого дампа. Потом этим запросом удаляем все повторяющиеся дампы.
Запрос выполнялся какое-то время, и, как видно из логов, кушал много памяти. На графике показано, как он каждую ночь забивал свободное пространство на диске:
Со временем запросу требовалось все больше памяти, провалы углублялись. И, заглянув в план выполнения, мы сразу увидели, куда все уходит:
Сортировка занимает много памяти. В плане выполнения из тестового набора данных сортировке требуется примерно 30 МБ памяти.
Почему так?
PostgreSQL выделяет память для хэширования и сортировки. Объем памяти управляется параметром work_mem . Размер work_mem по умолчанию — 4 МБ. Если для хэширования или сортировки нужно больше 4 МБ, PostgreSQL временно задействует пространство на диске.
Наш запрос потребляет явно больше 4 МБ, поэтому база данных использует столько памяти. Мы решили: спешить не будем, — и не стали увеличивать параметр и расширять хранилище. Лучше поискать другой способ урезать память для сортировки.
Экономная сортировка
"Сколько сортировка съест – зависит от размера набора данных и ключа сортировки. Набор данных не уменьшишь, а вот размер ключа — можно.
За точку отсчета возьмем средний размер ключа сортировки:
Каждый ключ весит 780. Чтобы уменьшить двоичный ключ, его можно хэшировать. В PostgreSQL для этого есть md5 (да, не секьюрно, но для нашей цели сойдет). Посмотрим, сколько весит BLOB, хэшированный с помощью md5:
Размер ключа, хэшированного через md5, — 36 байт. Хэшированный ключ весит всего 4% от исходного варианта.
Дальше мы запустили исходный запрос с хэшированным ключом:
И план выполнения:
С хэшированным ключом запрос потребляет всего 4 лишних мегабайта, то есть чуть больше 10% от прежних 30 МБ. Значит размер ключа сортировки сильно влияет на то, сколько памяти отъедает сортировка.
Дальше — больше
В этом примере мы хэшировали BLOB с помощью md5 . Хэши, созданные с MD5, должны весить 16 байт. А у нас получилось больше:
Наш хэш был ровно в два раза больше, ведь md5 выдает хэш в виде шестнадцатеричного текста.
В PostgreSQL можно использовать MD5 для хэширования с расширением pgcrypto . pgcrypto создает MD5 типа bytea (в двоичном виде):
Хэш все равно на 4 байта больше положенного. Просто тип bytea использует эти 4 байта, чтобы хранить длину значения, но мы этого так не оставим.
Оказывается, тип uuid в PostgreSQL весит ровно 16 байт и поддерживает любое произвольное значение, так что избавляемся от оставшихся четырех байтов:
Вот и все. 32 байта с md5 превращаются в 16 с uuid .
Я проверил последствия изменения, взяв набор данных побольше. Сами данные показывать нельзя, но я поделюсь результатами:
Как видно из таблицы, исходный проблемный запрос весил 300 МБ (и будил нас среди ночи). С ключом uuid сортировке потребовалось всего 7 МБ.
Соображения вдогонку
Запрос с хэшированным ключом сортировки памяти потребляет меньше, зато работает гораздо медленнее:
Хэширование задействует больше ЦП, поэтому запрос с хэшем работает медленнее. Но мы пытались решить проблему с пространством на диске, к тому же задача выполняется ночью, так что время — не проблема. Мы пошли на компромисс, чтобы сэкономить память.
Это отличный пример того, что не всегда нужно стараться ускорить запросы к базе данных. Лучше сбалансированно использовать что есть, и выжимать максимум из минимума ресурсов.
Взяв за основу статью Петра Зайцева об узких местах в производительности MySQL (MySQL Performance Bottlenecks), я хочу немного рассказать о PostgreSQL.
В наши дни для работы с PostgreSQL часто используются ORM-фреймворки. Обычно они работают хорошо, но со временем нагрузка увеличивается и возникает необходимость тюнить сервер базы данных. Каким бы надежным ни был PostgreSQL, но и он может тормозить при увеличении трафика.
Есть много способов устранения узких мест в производительности, но в этой статье мы обратим внимание на следующее:
- Параметры сервера
- Управление подключениями
- Настройка автоочистки (autovacuum)
- Дополнительная настройка автоочистки
- Раздувание таблиц (bloat)
- «Горячие точки» в данных
- Сервера приложений
- Репликация
- Серверное окружение
О «категориях» и «потенциальном влиянии»
«Сложность» говорит о том насколько просто реализовать предлагаемое решение. А «потенциальное влияние» дает представление о степени улучшений в производительности системы. Однако в силу возраста системы, ее типа, технического долга и т.п. точное описание сложности и влияния может быть проблематичным. В конце концов, в сложных ситуациях окончательный выбор всегда за вами.
- Сложность
- Низкая
- Средняя
- Высокая
- Низкая-средняя-высокая
Параметры сервера
Сложность: низкая.
Потенциальное влияние: высокое.Еще не так давно были времена, когда актуальные версии postgres могли работать на i386. С тех пор настройки по умолчанию были изменены, но они по-прежнему сконфигурированы на использование наименьшего количества ресурсов.
Эти параметры изменить очень просто и обычно они настраиваются при первоначальной установке. Неправильные значения этих параметров могут привести к высокой загрузке процессора и ввода-вывода:
- Параметр effective_cache_size ~ от 50 до 75%
- Параметр shared_buffers ~ 1/4 – 1/3 объема оперативной памяти
- Параметр work_mem ~ 10МБ
Вычисление значения shared_buffers — интересная головоломка. На нее можно смотреть с двух сторон: если у вас небольшая база данных, то можно установить значение shared_buffers достаточно большим, чтобы вся база данных поместилась в оперативной памяти. С другой стороны, можно настроить загрузку в память только часто используемых таблиц и индексов (вспоминайте правило 80/20). Раньше рекомендовалось устанавливать значение в 1/3 объема оперативной памяти, но со временем, так как объемы памяти росли, оно было уменьшено до 1/4. Если памяти выделено мало, то будет увеличиваться ввод-вывод и нагрузка на процессор. О слишком большом выделении памяти будет свидетельствовать выход на плато загрузки процессора и ввода-вывода.
Еще один фактор, который следует учитывать — это кэш ОС. При достаточном объеме оперативной памяти Linux будет кэшировать таблицы и индексы в памяти и, в зависимости от настроек, может заставить PostgreSQL поверить в то, что он читает данные с диска, а не из оперативной памяти. Одна и та же страница находится и в буфере postgres и в кэше ОС, и это одна из причин не делать shared_buffers очень большим. С помощью расширения pg_buffercache можно посмотреть использование кэша в реальном времени.
Параметр work_mem задает объем памяти, используемый для операций сортировки. Установка слишком низкого значения гарантирует плохую производительность, так как сортировка будет выполняться с использованием временных файлов на диске. С другой стороны, хотя установка большого значения и не влияет на производительность, но при большом количестве подключений есть риск нехватки оперативной памяти. Проанализировав память, используемую всеми запросами и сеансами, можно посчитать необходимое значение.
Используя EXPLAIN ANALYZE можно увидеть, как выполняются операции сортировки, и, изменяя значение для сеанса, определить момент, когда начинается слив на диск.
Можно также использовать бенчмарки системы.
Управление подключениями
Сложность: низкая.
Потенциальное влияние: низкое-среднее-высокоеВысокая нагрузка обычно связана с увеличением сессий клиентов в единицу времени. Слишком большое их количество может блокировать процессы, вызывать задержки или даже приводить к ошибкам.
Простое решение — увеличить максимальное количество одновременных подключений:
Но более эффективный подход — пул соединений. Существует множество решений, но наиболее популярное — pgbouncer. PgBouncer может управлять соединениями, используя один из трёх режимов:
- Пул сеансов (session pooling). Наиболее корректный подход. При подключении клиента ему выдается соединение и остается за ним, пока он не отключится. Когда клиент отключается, подключение возвращается в пул. Это метод по умолчанию.
- Пул транзакций (transaction pooling). Подключение назначается клиенту только на время транзакции. Когда PgBouncer замечает, что транзакция завершена, подключение возвращается в пул.
- Пул операторов (statement pooling). Наиболее агрессивный метод. Подключение к серверу будет возвращаться в пул сразу после завершения запроса. Транзакции с несколькими операторами в этом режиме запрещены, так как они будут прерываться.
Настройка автоочистки (autovacuum)
Сложность: средняя.
Потенциальное влияние: низкое-среднее.Управление параллельным доступом посредством многоверсионности (Multi-Version Concurrency Control) — один из основополагающих принципов, делающих PostgreSQL таким популярным решением среди СУБД. Однако одним из неприятных моментов является то, что для каждой измененной или удаленной записи создаются неиспользуемые копии, от которых в конечном итоге надо избавляться. Неправильно настроенный процесс автоочистки (autovacuum) может снижать производительность. При этом чем сервер загруженнее, тем сильнее проявляется проблема.
Для управления демоном автоочистки используются следующие параметры:
- Параметр autovacuum_max_workers. При наличии большого количества огромных таблиц стоит увеличить количество одновременно работающих процессов автоочистки (по умолчанию три). В идеале должен быть один рабочий процесс на один процессор, но не больше количества процессоров. Слишком большое количество может увеличить нагрузку на процессор. Обычно берется значение между двумя этими числами. Это баланс между максимальной эффективностью автоочистки и общей производительностью системы.
- Параметр maintenance_work_mem. Чем больше значение, тем эффективнее процесс очистки. Имейте в виду, что есть закон убывающей отдачи. Слишком большое значение в лучшем случае станет пустой тратой оперативной памяти, а в худшем может исчерпать всю доступную память.
- Параметр autovacuum_freeze_max_age уменьшает вероятность TXID WRAPAROUND. Чем значение больше, тем реже он запускается, что снижает нагрузку на систему. Но, как и со всеми параметрами автоочистки, упомянутыми выше, есть нюанс. Если сделать задержку слишком большой, то и вы рискуете исчерпать txid, что приведет к принудительному завершению работы сервера в целях защиты целостности данных. Для определения правильного значения необходимо сопоставлять самый большой/старый txid с процессом автоочистки используя pg_stat_activity на предмет WRAPAROUND.
Аналогично вычислению work_mem, это значение можно посчитать арифметически или выполнить бенчмарки для получения оптимальных значений.
Дополнительная настройка автоочистки
Сложность: высокая.
Потенциальное влияние: высокое.Этот метод, из-за его сложности, следует использовать только когда производительность системы уже на грани физических пределов хоста и это действительно стало проблемой.
Runtime-параметры автоочистки настраиваются в postgresql.conf . К сожалению, нет единого универсального решения, которое будет работать в любой высоконагруженной системе.
Параметры хранения для таблиц. Часто в базе данных значительная часть нагрузки ложится только на несколько таблиц. Настройка индивидуальных параметров автоочистки для таблицы — отличный способ не прибегать к ручному запуску VACUUM, который может существенно влиять на систему.
Настроить таблицы можно с помощью команды:
Раздувание таблиц (bloat)
Сложность: низкая.
Потенциальное влияние: среднее-высокое.Со временем производительность системы может ухудшаться из-за неправильных политик очистки, вследствие чрезмерного раздувания (bloat) таблиц. Так что даже настройка демона автоочистки и ручной запуск VACUUM не решает проблему. В этих случаях на помощь приходит расширение pg_repack.
С помощью расширения pg_repack можно перестроить и реорганизовать таблицы и индексы в условиях продакшена
«Горячие точки» в данных
Сложность: высокая.
Потенциальное влияние: низкое-среднее-высокое.Как и в случае с MySQL, избавление PostgreSQL от «горячих точек» зависит от ваших потоков данных и может даже повлечь за собой изменение архитектуры системы.
В первую очередь следует обращать внимание на следующее:
- Индексы. Убедитесь, что для столбцов, по которым осуществляется поиск есть индексы. Можно использовать системные каталоги и представления для мониторинга и проверки, что запросы используют индексы. Для анализа производительности запросов используйте расширения pg_stat_statement и pgbadger.
- Heap Only Tuples (HOT). Индексов может быть и слишком много. Снизить потенциальное раздувание и уменьшить размер таблицы можно, удалив неиспользуемые индексы.
- Секционирование таблиц. Ничто так не влияет на производительность, как огромная таблица, размер которой в несколько раз превышает средний размер других таблиц. Разбивка большой таблицы на более мелкие секции поможет повысить производительность запросов, например, при запросе данных, секционированных по дате. И так как таблица может обрабатываться только одним процессом автоочистки, то разбивка его на множество меньших таблиц позволяет более чем одному процессу автоочистки выполнять автоматическое удаление. Еще одно преимущество секционирования в том, что удаление большого количества строк намного эффективнее и быстрее, чем из единой огромной таблицы.
- Параллельные запросы. Появились в последних версиях postgres. Теперь для выполнения одного запроса может использоваться несколько процессоров, тогда как раньше запрос обрабатывался только одним.
- Денормализация. Можно повысить производительность, объединив столбцы из нескольких таблиц в одну таблицу. Повышение производительности достигается за счет увеличения избыточности данных. Тщательно обдумайте этот вариант, прежде чем его использовать!
Сервера приложений
Сложность: низкая.
Потенциальное влияние: высокое.Избегайте запуска приложений (PHP, Java и Python) и postgres на одном хосте. Относитесь внимательно к приложениям на этих языках, так как они могут потреблять большие объемы оперативной памяти, особенно сборщик мусора, что влечет за собой конкуренцию с системами баз данных за ресурсы и снижение общей производительности.
Репликация
Сложность: низкая.
Потенциальное влияние: высокое.Синхронная и асинхронная репликация. Последние версии postgres поддерживают логическую и потоковую репликацию как в синхронном, так и в асинхронном режимах. Хотя по умолчанию используется асинхронный режим репликации, но необходимо учитывать последствия использования синхронной репликации, особенно в сетях с существенной задержкой.
Серверное окружение
И последнее, но не менее важное — это простое увеличение мощности хоста. Давайте рассмотрим, на что влияет каждый из ресурсов в плане производительности PostgreSQL:
Жил на Винде-7, имел забитый на 70% 500Гб SSD диск, все было хорошо. Но потребовалось установить Ubuntu. Ставил через WUBI, т.к. другие более подробные мануалы по установке ниасилил. Сейчас при старте компа появляется выбор из 2 операционок (как надо) и еще какой-то Граб (по ошибке поверил одному описанию установки, но это вроде не мешает). Параметры системы: Память 3,6 ГиБ, Диск 18,2 ГБ. По команде free -h выдает
гуглил - пишут, что можно настраивать postgres, чтобы он не был таким прожорливым. А я не знаю, может у меня настолько мало свободной памяти, что это уже не поможет? И можно ли теперь как-то добавить еще памяти в систему, или уже поздно, диск размечался при установке? Переставлять все по новой? И весь установленный уже софт и т.п.? Что скажете, доктора?
А я не знаю, может у меня настолько мало свободной памяти, что это уже не поможет?
У тебя свободно примерно 1.8 Гб, постгрес настроен на то, чтобы откушать сразу 2.2Гб.
Настроить Postgres можно, но лучше ответить на вопрос, почему у тебя так мало памяти доступно на сервере. И почему некруглое число.
Ты где сервер видишь? У него десктоп на 4 гига, доступно 3.6
Deleted ( 10.10.17 22:20:59 )
Последнее исправление: Deleted 10.10.17 22:21:22 (всего исправлений: 1)Я поверил установщику, который по умолчанию запросил 18ГБ. И я не знаю куда делись остальные ГБ из этого числа. В другом месте пишет «Компьютер 8.3 ГБ / 18.2 ГБ Доступно» - и я не знаю почему отличается от показаний терминала. Сейчас то что делать? Имеет смысл параметры Постгреса крутить?
наверни свапца, места хватает же пока
Спасибо, навернул 5 ГБ (!) свапца, теперь из 2 докер-контейнеров стартует первый, а второй валится (раньше было наоборот :)). Но сейчас я могу их оба запустить руками не через compose а через docker start (хотя может так запускается не все что нужно, буду смотреть дальше). И да, со свапцом оно стало время от времени виснуть наглухо, перезгружаюсь регулярно.
ППЦ! тебе постгрес - для одноэс?
Я поверил установщику, который по умолчанию запросил 18ГБ.
Сейчас то что делать? Имеет смысл параметры Постгреса крутить?
Действительно, куда могло место деться…
Где запускается постгрес, там и сервер. Пусть даже он развёрнут на ноутбуке под подушкой.
Со свапцом жилось тяжко, все время зависала система, и много из того что нужно вообще не стартовало. Только что докупил один модуль памяти на 8 гигов - и навскидку все стало гораздо веселее, и даже работает. Насчет все/не все буду дальше смотреть.
Вообще моя материнка умеет в 32 гига максимум (есть 4 слота, можно во все поставить по 8 гигов), есть возможность для апгрейда еще. Просто по умолчанию стояла 32 бит Винда, которая не умеет физически больше 4 гигов ОЗУ подключать, поэтому и было такое железо.
При выполнении запросов на БД (Postgres) возникла ошибка:
24.02.21 13:50:38.219,main,ERROR,ExecSql,null
com.bssys.db.jdbc.DBSQLException: ОШИБКА: нехватка разделяемой памяти
Подсказка: Возможно, следует увеличить параметр max_locks_per_transaction.Подробная информация по параметру здесь. Коротко ниже:
max_locks_per_transaction (integer)
Этот параметр управляет средним числом блокировок объектов, выделяемым для каждой транзакции; отдельные транзакции могут заблокировать и больше объектов, если все они умещаются в таблице блокировок.- Получить ссылку
- Электронная почта
- Другие приложения
Комментарии
КБК. КВФО - Код вида финансового обеспечения (деятельности)
НПА: Приказ Минфина России от 01.12.2010 N 157н Письмо Минфина России от 18 января 2018 г. N 02-06-10/2715 В целях организации и ведения бухгалтерского учета, утверждения Рабочего плана счетов применяются следующие коды вида финансового обеспечения (деятельности): для государственных (муниципальных) учреждений, организаций, осуществляющих полномочия получателя бюджетных средств, финансовых органов соответствующих бюджетов и органов, осуществляющих их кассовое обслуживание: 1 - деятельность, осуществляемая за счет средств соответствующего бюджета бюджетной системы Российской Федерации (бюджетная деятельность); 2 - приносящая доход деятельность (собственные доходы учреждения); 3 - средства во временном распоряжении; 4 - субсидии на выполнение государственного (муниципального) задания; 5 - субсидии на иные цели; 6 - субсидии на цели осуществления капитальных вложений; 7 - средства по обязательному медицинскому страхованию; для отражения органами Федерального казн
TRUNCATE / DELETE / DROP или как очистить таблицу
ТФФ 33.0. Полный перечень документов альбома ТФФ (Таблица 2)
Таблицы в Oracle. Количество записей, размер таблицы
-- **************************************************************** -- выводим количество записей по таблицам -- **************************************************************** -- Требуется выполнить сначала скрипт с Set , после чего отдельно выполнить Declare Set serveroutput on format wraped; Declare Cou Integer; Begin For Rec in (select a.Table_Name from all_tables a where (a.OWNER = '<Имя_схемы>') ) loop Execute immediate('Select count(*) from '||Rec.Table_name) Into Cou; -- ************************************* dbms_output.put_line(' <Имя_схемы>'||Rec.Table_Name||';'||Cou); End Loop; End; Для того чтобы узнать размер таблицы в БД, требуется выполнить скрипт: select segment_name table_name, ceil(sum(bytes) / 1024) table_size from dba_segments where owner = ' <Имя_схемы>' aИмя_схемы>
VNC Viewer. Использование буфера обмена между Linux и Windows
Проблема: При работе на сервере через VNC Viewer не получается копировать куски текста, кода. Поэтому приходится вводить вручную. Решение: Первое решение, которое пока нормально работает. (возможно нужно найти возможность включения какой-либо настройки, но это потом в других вариантах). Необходимо выполнить следующую команду в терминале: [oracle@dbserver38 bin]$ vncconfig -display :1 В результате откроется окно, в котором (при необходимости необходимо поставить чекбоксы) После это можно копировать текст Для удобства, запихал данную команду в sh-файл на рабочем столе - VNC_copy_file.sh
Читайте также: