Linux
https://access.redhat.com/solutions/6189481
Memory Usage
ps -e -o pid,vsz,comm= | sort -n -k 2 | tail -n 5
ps aux | head -1; ps aux | sort -rnk 4 | head -5
ps aux | awk '{print $6/1024 " MB\t\t" $2 "\t" $11}' | sort -n
Linux Version Checking
RHEL / CENTOS
DNF / YUM Repo Mirroring, Syncing, Creation
Mirroring, Syncing, and Creating repos
Yum:
sudo yum install yum-utils createrepo
DNF:
sudo dnf install dnf-utils createrepo
To do the initial sync
mkdir -p /mnt/your/repo/mirror/here
reposync --repoid=REPOID --arch=x86_64 --plugins --download_path=/mnt/your/repo/mirror/here
This will sync whatever repoid (eg epel) you specify, only the x86_64 packages, will allow it to use the yum/dnf plugins, and sync it to your mirror dir. Omitting the repoid flag will sync ALL the repos on the system (/etc/yum.repos.d/)
Once the mirror is created you can sync it, verify it, and delete the old packages
reposync --repoid=REPOID -arch=x86_64 --plugins --gpgcheck --delete --download_path=/mnt/your/repo/mirror/here
If you need to do a quick sync you can add --newest-only
and it will just sync the newest packages. Adding the --download-metadata
flag might be needed for some repos. For example if you want to directly use the repo without running createrepo on it.
If you have a collection of RPMs that need to be put together in a repo, update a repo after running reposync, or fix a local mirror with bad metadata, use the createrepo
command.
If you have a large repo you will want to setup a cache. This will improve your entire repo creation speed at the cost of some disk space.
mkdir -p /mnt/your/repo/mirror/here/.repocache
createrepo --update --deltas --cachedir /mnt/your/repo/mirror/here/.repocache /mnt/your/repo/mirror/here
If you're having problems you can use the --workers
flag to set the number workers. By default it will use as many workers as you have threads. Another way of speeding up the process is to remove the --deltas
flag to prevent it from generating deltas. It may also be prudent to set nice & ionice levels depending on your system. For non-ssd storage, and/or SAN storage, I typically recommend limiting workers to no more than half of the available threads, nice level of 15, and ionice class of 3. This will make sure the system has plenty of resources to handle large repos without impacting other services. For SSD backed storage, especially local SSDs, ionice typically is not needed unless your storage throughput is limited by something like LUKS.
Redhat Monitoring and managing system status and performance
PDF - Redhat Monitoring and managing system status and performance.pdf
Security
Harding the boxes