пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Введение
Что такое стек и куча? И то, и то область памяти, но с разными механизмами распределения и управления ресурсами памяти. И то, и другое выступает в качестве хранилища данных, но они отличаются вариантами применения, жизненными циклами и функциональностью.
В некоторых языках программирования разработчики могут выделять память вручную. Но то, где находятся данные, в стеке или в куче, чаще всего зависит от типа данных и ограничений языка или платформы.
Давайте разберемся, чем же отличаются стек и куча, а также узнаем, почему они так важны для эффективного управления памятью и выполнения программ.
Что такое стек?
Стек – это определенная область памяти, где компьютерные программы в течение какого-то времени хранят данные. Это блок непрерывной памяти, где при вызове функции данные появляются, а при ее завершении – удаляются.
Стековая память работает по принципу «последним пришел – первым ушел» (LIFO - Last-In-First-Out). Иными словами, последний элемент, добавленный в стек, будет первым элементом, который будет оттуда удален (вытолкнут).
Когда программа получает указание выполнить функции посредством ее вызова, создается новый элемент, так называемый стековый кадр, и помещается в стек для вызова этой функции. Стековый кадр содержит:
Локальные переменные функции
Параметры, передаваемые в функцию
Возвратный адрес, который сообщает программе, где продолжить выполнение после завершения функции.
Прочая справочная информация, например, указатель базового регистра предыдущего кадра.
Когда выполнение функции завершится, стековый кадр выталкивается из стека, и система передает управление по возвратному адресу, который был указан в кадре.
Преимущества стека
Использование стековой памяти при выполнении программ дает следующие преимущества:
Быстрое выделение/освобождение памяти
. Выделение и освобождение памяти в стеке происходит быстро и осуществляется простой процедурой изменения значения указателя стека. Для того, чтобы выделить память, указатель стека перемещается вверх, а для того, чтобы освободить память, - вниз (в некоторых системах может быть наоборот).
Автоматическое управление памятью
. Управление пространством памяти в стеке происходит в автоматическом режиме. При вызове функции для локальных переменных автоматически выделяется пространство, а при выходе из функции оно освобождается.
Отсутствие фрагментации
. Память выделяется последовательно, что исключает фрагментацию памяти и обеспечивает эффективное использование свободного пространства.
Быстрый доступ к данным
. Последовательное выделение памяти обеспечивает грамотное расположение кэша. В результате, доступ к данным осуществляется быстро, а производительность повышается.
Прогнозируемый срок жизни
. Переменные в стеке существуют только в течение времени действия функции или области, в которой они находятся. Такая прогнозируемость упрощает написание и чтение кода.
Меньшее потребление ресурсов
. Выделение стековой памяти требует минимального количества ресурсов и не требует сложных алгоритмов и метаданных.
Недостатки стека
У стековой памяти много преимуществ, но у нее также есть и недостатки:
Ограниченный размер
. Память стека ограничена, и стоит ей закончится, как тут же происходит переполнение стека, что, в свою очередь приводит к сбою программы. Таким образом, стек непригоден для хранения больших объемов данных.
Примечание
: ограниченный размер стека является недостатком, но он также выполняет функцию механизма защиты. Система обнаруживает, что стек переполнен, и программа тут же завершает работу. А вот утечка памяти в куче может оставаться незамеченной в течение долгого времени, возможно, даже до тех пор, пока не будет израсходована вся доступная память системы.
Ограниченный доступ
. Принцип работы стека «последним пришел – первым ушел» означает, что все стандартные операции в первую очередь выполняются для вершины стека. Прямой доступ к другим ячейкам стека, находящимся за пределами текущей области, может привести к ошибкам.
Срок жизни переменных
. После того, как функция или блок кода, завершили свою работу, переменные освобождаются автоматически, что делает их непригодными для данных, которые необходимо хранить для нескольких функций.
Нельзя изменить размер
. После того, как блоки памяти были выделены в стеке, поменять их размер нельзя. Например, если вы выделите слишком мало памяти в стеке для массива, его размер нельзя будет изменить, как это можно было бы сделать в случае с динамически выделяемой памятью.
Отсутствие ручного управления
. Конечно, автоматическое выделение стековой памяти можно рассматривать как преимущество, но в случаях, когда требуется больший контроль над выделением и освобождением памяти, это недостаток.
Что такое куча?
Куча – это область памяти в компьютере, которая используется для динамического выделения памяти. В куче переменные необходимо создавать и удалять явным образом. Например, разработчики С и С++ для выделения и освобождения памяти используют такие функции и операторы, как
malloc()
,
free()
,
new
и
delete
.
Как правило, куча используется в следующих случаях:
Когда вы не знаете количество необходимой памяти для какой-либо структуры данных, например, массива или объекта, до начала выполнения программы
Когда вам нужно сохранить данные после завершения одного вызова функции
Когда существует вероятность того, что в будущем вам потребуется изменить размер выделенной памяти
Примечание
: в некоторых языках, например, Java и Python, есть сборщики мусора, которые автоматически освобождают неиспользуемую память.
Преимущества кучи
Выделение памяти с помощью кучи имеет несколько преимуществ:
Динамическое выделение памяти
. Программы могут выделять необходимое количество памяти непосредственно во время выполнения, что приводит к более эффективному использованию памяти.
Срок жизни переменных
. Объекты, хранящиеся в куче, будут находиться там до тех пор, пока память, выделенная под них, не будет явно освобождена или пока программа не завершится. Они способны «пережить» вызов функции, которая их создала, что крайне полезно, когда данные должны сохраняться после нескольких вызовов функции или даже на протяжении всей программы.
Большой пул памяти
. У кучи гораздо больший пул памяти, чем у стека. Она подходит для выделения памяти для более крупных структур данных или структур данных, которые могут расти, например, массивов или списков.
Гибкость
. Так как куча способна увеличиваться или уменьшаться в рамках доступной памяти в системе, она проще справляется с потребностями, меняющимися в процессе выполнения программы.
Глобальный доступ
. Куча доступна глобально, то есть к ней можно обращаться, и ее можно изменять из любой части кода, и она не привязана к стеку вызовов. Возможность использовать данные в разных частях программы или даже в разных потоках является очевидным преимуществом.
Возможность многократного использования
. После того, как память в куче была освобождена, ее можно использовать повторно, то есть выделять заново, что делает ее ресурсом многократного использования.
Поддержка сложных структур
. Куча позволяет создавать и управлять сложными структурами данных, например, деревьями, графами и связными списками, а это может требовать частого динамического выделения и освобождения памяти.
Недостатки кучи
Несмотря на то, что куча имеет множество преимуществ, у нее также есть ряд недостатков:
Ручное управление памятью
. Куча требует явного управления. Разработчикам необходимо вручную выделять и освобождать память, что может привести к потенциальным ошибкам и потреблению излишних ресурсов.
Утечки памяти
. Если после того, как функция завершилась, память не была освобождена, это может привести к утечкам памяти. Это значит, что программа продолжает потреблять память, что в конечном итоге приведет к ошибкам нехватки памяти, особенно это касается приложений, которые работают в течение длительного времени.
Фрагментация
. Память в куче выделяется и освобождается динамически. Это может привести к появлению неиспользуемых блоков памяти, разбросанных по всей куче (внешней фрагментации), или небольшим бесполезно использованным пространствам внутри выделенных блоков (внутренней фрагментации).
Медленный доступ
. Процесс получения доступа к переменным в куче, как правило, занимает больше времени, чем в стеке.
Висячие указатели.
Указатели, которые ссылаются на освобожденные области памяти, могут превратиться в висячие указатели. Доступ к данным или изменение данных с помощью таких указателей может привести к непредсказуемому поведению.
Проблемы с многопоточным выполнением
. Доступ к куче или ее изменение в нескольких потоках без надлежащей синхронизации может привести к повреждению данных.
Возможны ошибки.
Из-за того, что управление памятью в куче производится вручную, существует повышенная вероятность ошибок double-free (это когда разработчик пытается освободить уже освобожденную память).
Примечание
: чтобы предотвратить утечки памяти и непредвиденное поведение программы, всегда освобождайте память из кучи, когда она больше не нужна.
Стек и куча: различия
В следующей таблице продемонстрированы основные различия между стеком и кучей:
Параметр
Стек
Куча
Выделение памяти
Система выделяет память автоматически
Пользователь должен выделять память вручную
Структура
Память выделается в виде непрерывного блока (принцип LIFO)
Блоки памяти могут выделяться и освобождаться в любой момент времени
Скорость доступа
Быстрее за счет подхода LIFO
Медленнее за счет ручного поиска и управления блоками
Ограничение размера
Заранее определенный и фиксированный размер, ограниченный параметрами ОС
Больший изменяемый размер
Доступность
Привязан к стеку вызовов
Получить доступ к ней или изменить ее можно из любой части кода
Применение
Подходит для небольших структур данных с коротким жизненным циклом
Динамическое выделение памяти подходит для данных, размер которых определяется во время выполнения программы
Время жизни
Переменные стековой памяти освобождаются автоматически при выходе из функции или блока, где они находятся
Переменные существуют до тех пор, пока пользователь (или сборщик мусора, в зависимости от языка) не освободит его явным образом
Безопасность потоков
По природе потокобезопасен, так как каждый поток получает свой собственный стек
Безопасность потоков необходимо обеспечивать самостоятельно. Отсутствие синхронизации может привести к проблемам многопоточного выполнения
Гибкость
Размер фиксирован и устанавливает при запуске программы. Он не может динамически увеличиваться или уменьшаться
Гибкая и может увеличиваться и уменьшаться по мере необходимости
Фрагментация
Фрагментация отсутствует или минимальна
Может страдать фрагментацией и со временем приводить к неэффективному использованию памяти
Надежность
Меньше подвержен утечкам памяти
Ненадлежащее управление может привести к утечкам памяти или непредвиденному поведению
Стек или куча: что выбрать?
Выбирая между стеком и кучей, стоит учитывать такие факторы, как объем и жизненный цикл данных. В следующем списке представлены рекомендации по тому, когда нужно использовать стековую память, когда динамическую (кучу):
Стековую память следует использовать, когда:
Данные нужны только внутри определенной функции или блока и имеют ограниченный срок жизни
Вы работаете с небольшими структурами данных
Размерами данных можно управлять, а скорость доступа является критически важным фактором
Вы не хотите управлять памятью вручную
Данные должны быть ограничены определенной областью, например, одной функцией
Динамическую память следует использовать, когда:
Вам нужно, чтобы данные сохранялись за пределами функции, где они были созданы, или если у них неоднозначный жизненный цикл, который нельзя определить во время компиляции
Вы работаете с крупными структурами данных или их размер нельзя предсказать во время компиляции
Вам нужен больший контроль над памятью
Необходимо, чтобы данные были доступны из нескольких функций или областей
Структуры данных, например, массивы, которые могут увеличиваться, требуют изменения размера
Заключение
Теперь вы понимаете, чем отличается стек от кучи, и даже знаете их преимущества, недостатки и варианты применения.
Несмотря на то, что нельзя выбрать какой-то один тип памяти, изучение того, как каждый из них работает, поможет вам более эффективно управлять ресурсами памяти и лучше ориентироваться на нужды своего приложения.
Графический интерфейс Cisco Unified Communications Manager (CUCM) имеет раздел Disaster Recovery System (DRS), который предназначен для проведения резервного копирования (backup) и восстановления системы (restore). Но бывают ситуации, когда GUI недоступен, например, из-за проблем с сетью. В этом случае, провести процедуры бэкапирования и восстановления можно через консоль CLI и сейчас мы расскажем как это сделать.
Процедура бэкапа
Перед началом процедуры, у вас должен быть настрое SFTP сервер, куда вы будете заливать бэкап с CUCM.
Для начала нужно добавить сервер, куда мы будем загружать бэкап. Для этого вводим команду:
utils disaster_recovery device add network [number of backups]
Где:
backup device name - Имя устройства, куда будем заливать бэкап;
path - Путь, куда будем заливать бэкап на данном устройстве;
ip-address of remote server - IP адрес удалённого устройства;
username - Имя пользователя;
number of backups - Количество резервных копий
После ввода данной команды, вас попросят ввести пароль пользователя, из под которым вы хотите осуществить бэкап (в нашем случае - ccmadmin)
admin: utils disaster_recovery device add network merionbckp ./ 10.20.30.123 ccmadmin
Please enter password to connect to network server 10.20.30.123:****
drfCliMsg: Backup Device has been saved successfully.
Проверим, что устройство для бэкапа успешно добавилось, для этого введём команду:
utils disaster_recovery device list
В выводе мы должны увидеть устройство, добавленное ранее:
admin:utils disaster_recovery device list
Device Name Device Type Device Path
--------------------------------------------------------------
merionbckp NETWORK ./
Волшебно! Теперь мы можем осуществить бэкап. Для этого пишем в консоли:
utils disaster_recovery backup network
Где:
backup device name - Имя устройства, куда будем заливать бэкап;
featurelist - Список функционала, который нужно забэкапить;
Для того, чтобы посмотреть какой функционал доступен для бэкапирования наберите команду: utils disaster_recovery show_registration , где servername - имя сервера, на котором осуществляется бэкап.
admin:utils disaster_recovery backup network UCM,CDR_CAR,PLM merionbckp
drfCliMsg: Backup initiated successfully. Please run 'utils disaster_recovery status backup' command to see the status
Всё, бэкап запущен! Чтобы проверить статус, нам предлагают ввести: utils disaster_recovery status backup
admin:utils disaster_recovery status backup
Status: SUCCESS :Backup Completed...
Tar Filename: 2019-02-16-04-21-37.tar
Storage Location: NETWORK
Operation: backup
Percentage Complete: 100
PLM CCM01 ELM-AGENT SUCCESS Sat Feb 16 04:17:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sat Feb 16 04:17:26 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_plm_elm-server.log
CDR_CAR CCM01 CAR SUCCESS Sat Feb 16 04:17:27 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_cdr_car_car.log
UCM CCM01 BAT SUCCESS Sat Feb 16 04:19:23 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sat Feb 16 04:19:25 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sat Feb 16 04:19:30 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sat Feb 16 04:19:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sat Feb 16 04:19:35 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sat Feb 16 04:19:36 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_CCM01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sat Feb 16 04:19:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sat Feb 16 04:21:37 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sat Feb 16 04:21:33 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sat Feb 16 04:21:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_b_ccm01_ucm_moh.log
Всё, бэкап готов!
Процедура восстановления
Чтобы восстановить конфигурацию CUCM из бэкапа, нужно сначала посмотреть – что доступно для восстановления на удалённом сервере? Проверить это можно командой:
admin:utils disaster_recovery show_backupfiles merionbckp
2019-02-16-04-21-37
2018-12-25-21-52-19
Выбираем нужный нам бэкап и вводим следующую команду:
admin:utils disaster_recovery restore network 10.20.30.123 2019-02-16-04-21-37 merionbckp
drfCliMsg: WARNING! There are nodes in current production cluster but NOT present in the backup. These nodes will be removed if you restore the Publisher. If you want to keep these nodes, you will need to manually re-add them after the restore.
Do you want DRS to perform a SHA-1 File Integrity Check of your backup archives y/n ?(n) : y
Please enter the comma seperated features you wish to restore. Valid features for server CCM01 are PLM,CDR_CAR,UCM:PLM,CDR_CAR,UCM
Do you want to restore database from the subscriber y/n ?(n) : n
drfCliMsg: Restore initiated successfully. Please run 'utils disaster_recovery status restore' command to see the status
ALERT: Please restart the server(s) before performing the next restore for changes to take effect. In case of a cluster, restart the entire cluster.
Теперь проверяем статус восстановления:
admin:utils disaster_recovery status restore
Status: SUCCESS :Restore Completed...
Tar Filename: 2019-02-16-04-21-37.tar
Storage Location: NETWORK
Operation: restore
Percentage Complete: 100
CDR_CAR CCM01 CAR SUCCESS Sun Feb 17 11:20:15 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_cdr_car_car.log
PLM CCM01 ELM-AGENT SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-agent.log
PLM CCM01 ELM-SERVER SUCCESS Sun Feb 17 11:24:34 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_plm_elm-server.log
UCM CCM01 BAT SUCCESS Sun Feb 17 11:25:06 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_bat.log
UCM CCM01 CCMPREFS SUCCESS Sun Feb 17 11:37:06 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_ccmprefs.log
UCM CCM01 PLATFORM SUCCESS Sun Feb 17 11:37:13 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_platform.log
UCM CCM01 TCT SUCCESS Sun Feb 17 12:11:10 CEST 2019 activelog/platform/drf/log/2019-08-18-15-20-01_r_ccm01_ucm_tct.log
UCM CCM01 SYSLOGAGT SUCCESS Sun Feb 17 12:14:19 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_syslogagt.log
UCM CCM01 CDPAGT SUCCESS Sun Feb 17 12:14:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_cdpagt.log
UCM CCM01 CLM SUCCESS Sun Feb 17 12:17:03 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_clm.log
UCM CCM01 CCMDB SUCCESS Sun Feb 17 12:17:05 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ccmdb.log
UCM CCM01 TFTP SUCCESS Sun Feb 17 12:25:12 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_tftp.log
UCM CCM01 ANN SUCCESS Sun Feb 17 12:26:38 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_ann.log
UCM CCM01 MOH SUCCESS Sun Feb 17 12:26:39 CEST 2019 activelog/platform/drf/log/2019-02-16-04-21-37_r_ccm01_ucm_moh.log
Объем киберпреступности стремительно растет. Противостоять такому натиску становится все сложнее: в сочетании с нехваткой времени и персонала многие организации просто не могут справиться с объемом работ по обеспечению безопасности. Выход очевиден - автоматизация процессов управления рисками с помощью автоматизации.
Однако, как выяснил опрос профессионалов в области кибербезопасности, многие относятся с опаской к приходу "умных"технологий.
Разный взгляд на автоматизацию
Опрос проводила американская ИТ-компания Exabeam, ежегодно исследующая факторы, влияющие на эффективность работы специалистов по информационной безопасности.
Несмотря на то, что 88% профессионалов в области кибербезопасности считают, что автоматизация облегчит их работу, молодые сотрудники обеспокоены тем, что технологии их заменят.
53% респондентов в возрасте до 45 лет "согласны или полностью согласны с тем, что ИИ и машинное обучение - угроза их занятости", указывается в отчете компании.
В то же время только четверть профессионалов в области кибербезопасности старше 45 лет проявляет такое же беспокойство, отмечается в отчете.
"Есть свидетельства того, что автоматизация, искусственный интеллект и машинное обучение становятся все более популярными, но опрос этого года выявил поразительные различия между поколениями, когда дело доходит до профессиональной открытости и использования всех доступных инструментов для выполнения своей работы", - сказал Фил Рутли, старший менеджер Exabeam.
Тревога потерять работу
В опросе Exabeam 2020 участвовали более 350 профессионалов в области кибербезопасности из разных стран мира, ответившие на самые разные вопросы. Вряд ли можно делать всеобъемлющие выводы по столь небольшой выборке, однако некоторые тенденции все же можно отметить.
Неожиданным "открытием" опроса оказалась тревога молодых по поводу своей карьеры, опасения потерять свое место с приходом машин.
"Отношение к автоматизации среди молодых специалистов в области кибербезопасности было для нас удивительным. Возможно, такое отношение связано с отсутствием обучения технологиям автоматизации", - говорится в пресс-релизе Exabeam.
Аналитики компании отмечают, что отсутствие понимания важности автоматизации и нехватка знаний и навыков могут повлиять на безопасность работы компаний.
Согласно данным исследования Cybersecurity Workforce 2019 года, в сфере кибербезопасности работают 2,8 миллиона человек, а требуется еще 4 млн. На фоне такой нехватки кадров обеспокоенность молодежи заставляет задуматься.
Вероятнее всего, главная причина подобных "страхов" - непонимание, в какой степени машины могут участвовать в работе, и будут ли они отрицать потребность в человеческом персонале.