Несмотря на кажущуюся простоту, компьютер состоит из большого числа частей, и быстродействие системы определяется тремя факторами: (1) скоростью работы каждой компоненты, (2) согласованием быстродействия разных компонент и (3) точной настройкой системы для работы именно с этой конфигурацией аппаратуры. Здесь мы не будем касаться первых двух факторов и предположим, что мы имеем идеально согласованную конфигурацию аппаратных средств. Поскольку в реальной жизни такое встречается редко, наш глаз отдыхает при взгляде на этот прекрасный компьютер. Все, что мы можем сделать с ним, – это установить подходящую операционную систему и настроить ее оптимальным образом.
Оптимизации подлежит следующее:
Вопросы анализа и увеличения производительности дисковой подсистемы будут изложены позже, сейчас мы затрагиваем только тему оптимизации работы процессов. Фактически, в этой лекции обсуждаются два вопроса: оптимизация использования памяти и оптимизация приоритетов процессов. Первый, как легко догадаться, в практических задачах встречается много чаще.
Начнем с изучения того, как устроена виртуальная память в Solaris, ибо она является первым по значимости ресурсом, который постоянно делят между собой все процессы, запущенные в системе.
Поскольку процессам, запущенным в системе, обычно в сумме требуется больше места, чем размер оперативной памяти, в любой системе UNIX существует механизм виртуальной памяти. Объем виртуальной памяти складывается из объема оперативной памяти и объема пространства свопинга (
Вся виртуальная память разбита на страницы объемом 4 Кб. Некоторые компьютеры в силу их аппаратной реализации используют страницы памяти по 8Кб. К ним относятся компьютеры с микропроцессорами DEC Alpha, первыми процессорами Sun SPARC (например, Ross RT601/Cypress CY7C601/getpagesize(3C).
Потребителями виртуальной памяти в Solaris являются ядро системы, кэши файловой системы, тесно разделяемая память (intimately shared memory) и процессы. Тесно разделяемая память специфична для Solaris и представляет собой область разделяемой памяти, которую нельзя выгружать на диск. Тесно разделяемую память используют такие программы, как Oracle, Sybase, Informix.
Виртуальная память построена на четырех принципах, реализованных в системе.
Во-первых, каждый процесс получает отдельное виртуальное адресное пространство (
Во-вторых, адресные пространства нескольких процессов могут перекрываться незаметно для процессов, если они используют общий код. Например, одновременно могут быть запущены три экземпляра одного и того же командного процессора (пусть это будет bash ). Они имеют отдельные виртуальные адресные пространства. В каждом виртуальном пространстве находится экземпляр процесса командного интерпретатора, копия библиотеки libc и (возможно) копии других разделяемых процессами ресурсов. Подсистема виртуальной памяти незаметно для процессов отображает эти разделяемые куски памяти в одну и ту же область физической памяти так, что в физической памяти содержится всего один экземпляр разделяемого ресурса. Похоже на создание жестких ссылок на файл, верно?
В-третьих, подсистема виртуальной памяти выгружает наименее используемые страницы памяти на диск, когда физической памяти не хватает для всех процессов.
В-четвертых, подсистема виртуальной памяти запрещает процессу обращаться к ячейкам памяти из чужого адресного пространства, причем это делается на аппаратном уровне – посредством механизма диспетчеризации.
Для оценки памяти, занимаемой каждым из процесов, можно использовать как уже известные top и ps, так и pmap (последняя дает более подробное распределение памяти процесса по типам – разделяемая память и т.п.):
pmap –х
Вообще говоря, в Solaris существует целое семейство так называемых процессных утилит (proc tools) или p -команд, которые работают с файловой системой /proc, в которую отображаются многие структуры ядра, в частности, таблица процессов. Эти программы позволяют получать самую разную информацию о процессах, а некоторые из них могут также проанализировать завершившийся аварийно процесс, если от него остался файл core записывается в текущий каталог процесса в случае аварийного завершения; случаи прерывания процесса по сигналам KILL, TERM и HUP к этому не относятся. Имя файла – всегда core, независимо от имени файла, который был запущен для порождения аварийного процесса. Файл core представляет собой дамп памяти (всех сегментов) процесса, поэтому его можно проанализировать так же, как запущенный процесс: это – моментальный снимок памяти процесса на момент аварийного завершения (прим. авт.).
Помните, что память потребляется не только процессами, но и кэшем файловой системы, тесно разделяемой памятью и ядром! Если в системе не запускается СУБД Oracle или другое подобное приложение, скорее всего, тесно разделяемая память в системе не используется. В Solaris 8 и Solaris 9 для ядра и обязательно запускающихся системных приложений следует заранее предусмотреть не менее 32 MB памяти и еще 16 MB, если CDE (
Если пользователи обращаются только к нескольким сотням мегабайт данных, но делают это часто, то для кэширования всех этих данных должно хватать оперативной памяти. Это радикально ускорит их работу.
Список свободных страниц – это набор страниц, из которого страницы извлекаются по запросу процессов. Управление распределением памяти между процессами основано на этом списке. Процессы берут память из него и возвращают ее обратно по завершении. Сканер страниц также возвращает память в список свободных страниц.
Каждый раз, когда процесс запрашивает память, происходит так называемая
Процесс попытался получить доступ к странице, которая была изъята сканером страниц, но пока еще не использована повторно другим процессом.
Процесс пытается получить доступ к странице, изъятой сканером страниц, использованной повторно и в данный момент уже отданной другому процессу.
Процесс пытается записать данные в страницу памяти, которая используется совместно с другими процессами.
Сейчас нам важны некоторые основные моменты, связанные с производительностью процессов.
После загрузки системы вся виртуальная память распределяется между процессами постранично. Кроме того, в ядре инициализируется специальная таблица, в которой хранятся состояния страниц. Несколько мегабайт памяти ядро резервирует для себя, а оставшееся пространство отходит списку свободных страниц. В какой-то момент, когда процесс запрашивает память, из списка свободных страниц извлекается одна страница, которая поступает в распоряжение процесса. Такая схема, при которой память выдается по принципу "когда потребуется", называется выделением страниц по запросу (demand paging).
Если список свободных страниц уменьшается до размера lotsfree (см. лекцию 8), ядро запускает специальный поток внутри себя – сканер страниц. Он начинает искать страницы, которые можно выгрузить на диск, чтобы увеличить размер свободной памяти и пополнить список свободных страниц. Дабы не выгрузить страницы, к которым часто обращаются, сканер страниц работает по двухшаговому алгориму. Просматривая оперативную память в порядке возрастания адресов, он очищает бит slowscan и fastscan определяют то время, которое пройдет между очисткой бита
slowscan – первоначальная частота сканирования. При увеличении этого значения сканер страниц выполняет меньше ненужных заданий, но делает больше работы;fastscan – частота сканирования в ситуации, когда свободной памяти не осталось.Далее демон страниц снова просматривает память. Если ссылочный бит какой-то страницы по-прежнему в исходном состоянии, то значит, к этой странице не обращались.
Те страницы, чей бит "используемости" не был изменен в течение некоторого времени, выгружаются на диск и освобожденная память пополняет список свободных страниц.
Некоторые страницы (например, принадлежащие разделяемым библиотекам) могут разделяться между многими процессами, и при записи в такую страницу возникает ошибка копирования при записи (copy-on-write fault). Как только это произойдет, из списка свободных страниц извлекается чистая страница и создается копия первоначальной разделяемой страницы для того процесса, который требовал записать данные; в дальнейшем процесс работает именно со своей копией разделяемой страницы. Когда процесс завершается, все его страницы, за исключением тех, которые он делил с другими процессами, возвращаются в список свободных страниц.
Сейчас мы, как минимум, должны представлять себе, что если программа vmstat сообщает о постоянной активности устройства свопинга, а частота сканирования страниц высока (а в Solaris 8 и более новых версиях она вообще должна быть близка к нулю в обычной ситуации), то следует подумать об уменьшении числа одновременно запущенных процессов или увеличении объема оперативной памяти.
Следует всегда запускать ровно столько экземпляров служб (демонов, daemons), сколько требуется. Например, если компьютер не является сервером NFS, не следует создавать файл /etc/dfs/dfstab, так как при его наличии автоматически запускается некоторое количество процессов, связанных со службой NFS. Мало того, что ненастроенные демоны могут дать злоумышленнику неожиданный доступ к компьютеру, так еще и память занимают. Всегда используйте
ps –ef
для контроля за количеством запущенных процессов. Не оставляйте без внимания запущенные процессы: если среди них есть незнакомый вам процесс, стоит почитать man по нему, чтобы выяснить, нужен ли он в вашей конфигурации.
Некоторые программы, такие, как веб-сервер Apache или прокси-сервер squid, запускают несколько процессов, размножая самих себя или вспомогательные службы для увеличения производительности. По умолчанию количество запускаемых ими процессов сделано "средним", т.е. для слабо нагруженной системы оно слишком велико, а для перегруженной внешними запросами – слишком мало. Постарайтесь установить оптимальное значение – так вы сможете выиграть от нескольких мегабайт до нескольких сотен мегабайт памяти.
Проектом в Solaris называется единица администрирования, предназначенная для оптимального управления ресурсами системы. К проекту могут относиться любые пользователи и группы, и каждый пользователь или группа могут входить в несколько проектов. В большой системе удобно определить ряд проектов в базе проектов (файле /etc/project или соответствующем файле базы NIS).
Проект характеризуется уникальным идентификатором проекта ( PROJID ). Каждый пользователь обязательно относится к некоему проекту по умолчанию, и какой именно это проект, определяется при входе пользователя в систему. Пользователь обязательно имеет главный проект (по аналогии с главной группой) но может участвовать в нескольких проектах.
Каждый процесс также обязательно ассоциируется с каким-нибудь проектом. Это не обязательно главный проект пользователя, запустившего процесс, так как пользователь волен отнести запущенный им процесс к любому из проектов, участником которых он является. Отнести пользователя или группу к проекту можно либо в описании пользователя в файле /etc/user_attr, либо в файле проектов /etc/project. Для тех случаев, когда администратор не озаботился отнесением пользователей к определенным проектам, в системе имеется предопределенный проект default – к нему относятся все пользователи, группы и процессы, для которых явным образом не указано иное.
Главный проект пользователя определяется при входе в систему следующим образом:
/etc/user_attr запись об этом пользователе имеет атрибут project, то в качестве главного проекта пользователю назначается указанный таким образом проект;/etc/project имется проект с именем user.UID, где UID совпадает с UID пользователя, то он назначается главным проектом пользователя;/etc/project есть проект group.groupname и groupname совпадает с именем главной группы пользователя, то этот проект назначается главным пользователю;default, то главным назначается он.Проверка перечисленных условий производится в указанном выше порядке. В качестве базы данных проектов может использоваться не только файл /etc/project, но и база данных NIS или LDAP. Порядок обращения к службам имен (файлу, NIS или LDAP) определяется в файле /etc/nsswitch.conf:
project: files nis ldap
При использовании PAM может быть полезно также изучить страницу руководства pam_projects(5).
Если при входе для пользователя не удалось определить главный проект, вход пользователю запрещается.
Изменения, внесенные в базу данных проектов, коснутся только процессов, которые будут запущены, и пользователей, которые войдут в систему после сохранения изменений. На уже запущенные процессы и уже работающих пользователей они не повлияют.
Файл /etc/project имеет следующий формат:
projname:projid:comment:user-list:group-list:attributes
где:
projname – это имя проекта (в нем не должно быть точек, запятых или двоеточий);projid - это уникальный идентификатор проекта (неотрицательное целое число не больше 2147483647;comment – описание проекта;user-list – список пользователей, входящих в проект, имена через запятую;group-list – список групп, входящих в проект, имена групп через запятую;attributes – атрибуты проекта в формате имя=значение.Везде, где указано "список", может стоять звездочка (подразумевает "все"), имя может быть предварено восклицательным знаком, что означает "кроме этого" ( !groupname – все указанные группы, кроме groupname ).
По умолчанию файл /etc/project выглядит так:
system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10::::
Помимо редактирования файла вручную вы можете пользоваться программами projadd, projmod и projdel для добавления, изменения или удаления проектов. Для получения информации о соответствии процессов проектам следует запускать программы ps, id, pgrep, prstat:
ps -o user,pid,uid,projid USER PID UID PROJID root 672 0 1 root 625 0 1 root 654 0 1 root 652 0 1 root 808 0 1 id –p uid=0(root) gid=1(other) projid=1(user.root)
Синтаксис вызова pgrep:
pgrep –J projidlist
например:
pgrep -J 1 | more 347 460 461 345 368 426 435 378 427 411 412 414 434 436 438 459 463 467 469 470 649 650 prstat -J PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 345 root 63M 14M sleep 59 0 0:01:35 0,8% Xsun/1 622 root 15M 2532K sleep 59 0 0:00:02 0,6% dtterm/1 470 root 141M 55M sleep 49 0 0:02:07 0,5% soffice.bin/4 820 root 7624K 4576K cpu0 59 0 0:00:00 0,3% prstat/1 672 root 4728K 696K sleep 49 0 0:00:00 0,0% bash/1 652 root 24M 3784K sleep 49 0 0:00:01 0,0% sdtimage/1 654 root 79M 10M sleep 19 0 0:00:08 0,0% java/15 195 root 5660K 0K sleep 59 0 0:00:00 0,0% syslogd/13 175 root 2160K 0K sleep 59 0 0:00:00 0,0% lockd/2 170 root 3028K 0K sleep 59 0 0:00:00 0,0% in.named/1 237 root 1348K 0K sleep 59 0 0:00:00 0,0% powerd/2 183 root 6108K 644K sleep 59 0 0:00:00 0,0% automountd/3 322 root 4360K 0K sleep 59 0 0:00:00 0,0% snmpdx/1 347 root 8632K 0K sleep 59 0 0:00:00 0,0% dtlogin/1 158 root 2412K 0K sleep 59 0 0:00:00 0,0% inetd/1 PROJID NPROC SIZE RSS MEMORY TIME CPU PROJECT 1 30 480M 99M 84% 0:04:00 2,3% user.root 0 38 135M 5788K 4,8% 0:00:00 0,0% system Total: 68 processes, 185 lwps, load averages: 0,04, 0,14, 0,14
Эта программа выполняется как интерактивная в полноэкранном режиме (подобно top).
В системе Solaris, начиная с версии 9 выпуска 12/03, появился демон ограничения ресурсов (Resource Capping Daemon), который управляет тем, как процессы используют оперативную память. Управление выполняется на по-проектной основе, т.е. ресурсы ограничиваются для конкретных проектов.
Демон ограничения ресурсов rcapd занимается ограничением потребления физической памяти для процессов, относящихся к проектам с установленными ограничениями. Существуют также программы rcapstat, rcapadm, предоставляющие возможность управления работой rcapd и получения статистики.
Настройка таблиц диспетчера памяти осуществляется в три этапа:
Работа по выводу и загрузке таблиц осуществляется с помощью программы dispadmin.
Попробуем модифицировать таблицу диспетчера для класса разделения времени так, чтобы ни один процесс не занял приоритета 59 и ни один процесс не лишился этого приоритета, если мы его присвоим. Это может быть полезно для систем, где некие задачи надлежит вручную запускать с повышенныим приоритетом. Конечно, это привнесет несправедливость в
Посмотрим, как сейчас себя ведут наши процессы:
top last pid: 825; load averages: 0.05, 0.11, 0.12 20:35:24 68 processes: 67 sleeping, 1 on cpu CPU states: 99.8% idle, 0.2% user, 0.0% kernel, 0.0% iowait, 0.0% swap Memory: 128M real, 12M free, 206M swap in use, 387M swap free PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND 825 root 1 59 0 2260K 1340K cpu 0:00 0.61% top 345 root 1 59 0 57M 8648K sleep 1:37 0.35% Xsun 470 root 4 49 0 141M 55M sleep 2:11 0.28% soffice.bin 622 root 1 59 0 15M 2928K sleep 0:02 0.03% dtterm 461 root 1 49 0 15M 1864K sleep 0:03 0.00% dtterm 654 root 15 19 10 79M 10M sleep 0:08 0.00% java 434 root 5 59 0 22M 4060K sleep 0:04 0.00% dtwm 652 root 1 49 0 24M 3784K sleep 0:01 0.00% sdtimage 435 root 1 49 0 16M 1216K sleep 0:00 0.00% dtfile 672 root 1 49 0 4728K 740K sleep 0:00 0.00% bash 427 root 1 49 0 18M 0K sleep 0:00 0.00% dtsession 467 root 1 49 0 4728K 0K sleep 0:00 0.00% bash 650 root 1 49 0 3460K 0K sleep 0:00 0.00% more 649 root 1 49 0 3356K 0K sleep 0:00 0.00% sh 634 root 1 49 0 3304K 0K sleep 0:00 0.00% man
А теперь пусть приоритет 59 может получать только та программа, которой мы это разрешим, по умолчанию – всем нельзя.
Для этого мы сначала модифицируем таблицу диспетчера так, чтобы ни один процесс не получил приоритета 59. Вначале выведем текущую таблицу приоиритетов:
dispadmin -c TS -g > prior
Файл
# Time Sharing Dispatcher Configuration RES=1000 # ts_quantum ts_tqexp ts_slpret ts_maxwait ts_lwait PRIORITY LEVEL 200 0 50 0 50 # 0 200 0 50 0 50 # 1 200 0 50 0 50 # 2 200 0 50 0 50 # 3 200 0 50 0 50 # 4 200 0 50 0 50 # 5 200 0 50 0 50 # 6 200 0 50 0 50 # 7 200 0 50 0 50 # 8 200 0 50 0 50 # 9 160 0 51 0 51 # 10 160 1 51 0 51 # 11 160 2 51 0 51 # 12 160 3 51 0 51 # 13 160 4 51 0 51 # 14 160 5 51 0 51 # 15 160 6 51 0 51 # 16 160 7 51 0 51 # 17 160 8 51 0 51 # 18 160 9 51 0 51 # 19 120 10 52 0 52 # 20 120 11 52 0 52 # 21 120 12 52 0 52 # 22 120 13 52 0 52 # 23 120 14 52 0 52 # 24 120 15 52 0 52 # 25 120 16 52 0 52 # 26 120 17 52 0 52 # 27 120 18 52 0 52 # 28 120 19 52 0 52 # 29 80 20 53 0 53 # 30 80 21 53 0 53 # 31 80 22 53 0 53 # 32 80 23 53 0 53 # 33 80 24 53 0 53 # 34 80 25 54 0 54 # 35 80 26 54 0 54 # 36 80 27 54 0 54 # 37 80 28 54 0 54 # 38 80 29 54 0 54 # 39 40 30 55 0 55 # 40 40 31 55 0 55 # 41 40 32 55 0 55 # 42 40 33 55 0 55 # 43 40 34 55 0 55 # 44 40 35 56 0 56 # 45 40 36 57 0 57 # 46 40 37 58 0 58 # 47 40 38 58 0 58 # 48 40 39 58 0 59 # 49 40 40 58 0 59 # 50 40 41 58 0 59 # 51 40 42 58 0 59 # 52 40 43 58 0 59 # 53 40 44 58 0 59 # 54 40 45 58 0 59 # 55 40 46 58 0 59 # 56 40 47 58 0 59 # 57 40 48 58 0 59 # 58 20 49 59 32000 59 # 59
Теперь мы его изменяем так как нам надо, и он становится иным (показаны только измененные последние две строки):
# ts_quantum ts_tqexp ts_slpret ts_maxwait ts_lwait PRIORITY LEVEL 40 48 58 32000 58 # 58 20 59 59 0 59 # 59
Загружаем этот файл, запустив
dispadmin -c TS -s prior
Смотрим вывод top:
last pid: 836; load averages: 0.14, 0.14, 0.13 20:43:48 68 processes: 66 sleeping, 1 running, 1 on cpu CPU states: 94.8% idle, 5.0% user, 0.2% kernel, 0.0% iowait, 0.0% swap Memory: 128M real, 10M free, 204M swap in use, 389M swap free PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND 470 root 4 49 0 141M 57M sleep 2:34 7.64% soffice.bin 345 root 1 59 0 56M 7228K sleep 1:46 0.86% Xsun 836 root 1 59 0 2260K 1336K cpu 0:00 0.77% top 622 root 1 59 0 15M 2972K sleep 0:02 0.03% dtterm 672 root 1 48 0 4728K 1176K sleep 0:00 0.03% bash 654 root 15 49 0 79M 11M run 0:08 0.02% java 461 root 1 49 0 15M 1924K sleep 0:03 0.02% dtterm 434 root 5 59 0 22M 4084K sleep 0:04 0.00% dtwm 652 root 1 49 0 24M 3784K sleep 0:01 0.00% sdtimage 435 root 1 49 0 16M 1216K sleep 0:00 0.00% dtfile 427 root 1 49 0 18M 0K sleep 0:00 0.00% dtsession 467 root 1 49 0 4728K 0K sleep 0:00 0.00% bash 650 root 1 49 0 3460K 0K sleep 0:00 0.00% more 649 root 1 49 0 3356K 0K sleep 0:00 0.00% sh 634 root 1 49 0 3304K 0K sleep 0:00 0.00% man
Те процессы, которые по-прежнему имеют приоритет 59, можно перезапустить.
Выявим их по команде
ps –ecL | grep 59.
остановим и перезапустим. Кроме того, можно регулировать приоритет процесса напрямую с помощью команды priocntl, как показано ниже. Понизим на 20 единиц приоритет всех процессов в классе разделения времени:
priocntl -s -c TS -p -20
Снова запускаем top:
last pid: 987; load averages: 0.00, 0.03, 0.07 21:00:41 66 processes: 65 sleeping, 1 on cpu CPU states: 99.4% idle, 0.0% user, 0.6% kernel, 0.0% iowait, 0.0% swap Memory: 128M real, 6188K free, 202M swap in use, 391M swap free PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND 984 root 1 58 0 2260K 1336K cpu 0:00 0.11% top 345 root 1 58 0 56M 7184K sleep 1:52 0.07% Xsun 622 root 1 58 0 15M 3500K sleep 0:03 0.02% dtterm 470 root 4 48 0 141M 57M sleep 2:40 0.00% soffice.bin 654 root 15 58 0 79M 13M sleep 0:08 0.00% java 434 root 5 58 0 22M 4360K sleep 0:04 0.00% dtwm 461 root 1 58 0 15M 2628K sleep 0:03 0.00% dtterm 652 root 1 58 0 24M 5312K sleep 0:01 0.00% sdtimage 349 root 7 39 6 4532K 704K sleep 0:00 0.00% mibiisa 212 root 18 49 3 2872K 720K sleep 0:00 0.00% nscd 435 root 1 58 0 16M 1908K sleep 0:00 0.00% dtfile 436 root 1 58 0 16M 1864K sleep 0:00 0.00% sdtperfmeter 427 root 1 58 0 18M 1368K sleep 0:00 0.00% dtsession 672 root 1 58 0 4732K 1196K sleep 0:00 0.00% bash 276 root 1 58 0 2068K 580K sleep 0:00 0.00% xntpd
Настройку диспетчерских таблиц следует проводить с осторожностью. Неверные действия могут привести к потере устойчивости и неполадкам в работе производственной системы. Тестируйте внимательно!
Регулировать приоритет процесса, как показано выше, можно с помощью команды priocntl. Ключ -s означает требование установить приоритет. Ключ -p позволяет задать относительное изменение приоритета, а для указания конкретного признака процесса (идентификатора и т.п.) следует использовать ключ -i (признак идентификатора обозначается pid, другие признаки поименованы в руководстве по priocntl ).
Например, для понижения приоритета процесса с PID, равным 200, используйте
priocntl -s -c TS -p –20 –i pid 200
Для вывода списка части процессов с заголовком вместе, применяйте POSIX-совместимую программу grep:
/usr/bin/ps -ecL |/usr/xpg4/bin/grep -E 'nscd|PID'
Алгоритм пейджинга и свопинга в Solaris предусматривает возможность явного указания границ свободной памяти в системе, по достижении которых начинается вначале активный пейджинг (выгрузка отдельных страниц), а при дальнейшем уменьшении свободной памяти – свопинг (выгрузка всех страниц процесса сразу).
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.