Таким образом, на очень хорошем хосте есть устаревшие шаблоны CentOS 6.x VPS, которые «застряли» на 100 МБ / загрузочном разделе. К сожалению, поскольку он был создан ~ 4 года назад, один из наших серверов попадает в эту категорию. За исключением изменения зон для получения нового пакета / шаблона с большим объемом, нет никакого способа увеличить размер / boot. Переключение зон было бы сложной задачей, поскольку нужно было бы переделывать новые IP-адреса и другие схемы, поэтому мы ищем альтернативы.
Мы используем CloudLinux на этом сервере, поэтому, возможно, ядра немного больше, чем обычно. В любом случае мы вынуждены сократить количество активных ядер до 1, что меня беспокоит, но это все, что может поместиться в / boot. Проблема в том, что для установки новых версий ядра не хватает места.
Пакеты Kernel-debug * кажутся больше стандартного ядра. Это безопасно удалить? Полезны ли отладочные ядра в производственной среде, если для загрузки [потенциально] доступна более старая версия стандартного ядра?
Это многопользовательский производственный VPS (KVM) под управлением LAMP. Мы не делаем для этого много CLI на стороне сервера, в основном это ecom + webapps. У него есть kernelcare, если это может предоставить какое-то обходное решение.
Под kernel-debug * вы имеете в виду как kernel-debug, так и kernel-debuginfo, поскольку между этими двумя пакетами есть разница.
Kernel-debuginfo: Provides a executable image of the kernel with all the debug symbols
Kernel-debug: Enables some debugging code but not have same debug symbols on it
### Excerpt from RedHat Doc ###
The kernel-debug enables the following options on the kernel that are disabled on the default kernel:
CONFIG_DEBUG_SLAB
Makes kernel do limited verification on memory allocation as well as poisoning memory on free to catch use of freed memory. (performance impact mainly on kmalloc / mfree calls).
CONFIG_DEBUG_MUTEXES
Allows mutexes semantics violations to be detected and reported.
CONFIG_DEBUG_RT_MUTEXES
Allows rt mutex semantics violations and rt mutex related deadlocks (lockups) to be detected and reported automatically.
CONFIG_DEBUG_RWSEMS
Allows read-write semaphore semantics violations to be detected and reported.
CONFIG_DEBUG_LOCK_ALLOC
This feature will check whether any held lock (spinlock, rwlock, mutex or rwsem) is incorrectly freed by the kernel, via any of the memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), vfree(), etc), whether a live lock is incorrectly reinitialized via spin_lock_init(),mutex_init(),etc, or whether there is any lock held during task exit.
CONFIG_PROVE_LOCKING
This feature enables the kernel to prove that all locking that occurs in the kernel runtime is mathematically correct: that under no circumstance could an arbitrary (and not yet triggered) combination of observed locking sequences (on an arbitrary number of CPUs, running an arbitrary number of tasks and interrupt contexts) cause a deadlock.
CONFIG_DEBUG_VM
Turn on extended checks in the virtual memory system (performance impact).
CONFIG_DEBUG_SPINLOCK
Built SMP to catch missing spinlock initialization and certain other kinds of spinlock errors commonly made. This is best used in conjunction with the NMI watchdog so that spinlock deadlocks are also debuggable.
CONFIG_DEBUG_SPINLOCK_SLEEP
Various routines which may sleep will become very noisy if they are called with a spinlock held.
CONFIG_LOCK_STAT
Enables tracking lock contention points ( see /usr/share/doc/kernel-doc/Documentation/lockstat.txt ).
CONFIG_XFS_DEBUG
Enable XFS debugging features, including ASSERT checks, function wrappers around macros, and extra sanity-checking functions in various code paths (make a huge and slow code).
Теперь возвращаясь к вашему вопросу. Безопасно ли их удалять?
Эти пакеты предназначены только для целей отладки, и они могут вызвать снижение производительности ... Так что, да, их можно безопасно удалить, и их нужно устанавливать только во время отладки.