#cli

Największe klucze

redis-cli --bigkeys

Przechodzi SCAN-em po całej bazie i pokazuje największy klucz każdego typu.

Uwaga na jednostki: dla stringów liczy bajty, dla kolekcji liczbę elementów. Lista z milionem krótkich wpisów wyjdzie tu „większa” niż jeden string na 10 MB.

Ile to waży naprawdę

redis-cli --memkeys

To samo przejście, ale liczone przez MEMORY USAGE — czyli faktyczne bajty. Wolniejsze, za to nie kłamie. Od Redisa 6.

Pojedynczy klucz:

redis-cli MEMORY USAGE klucz

Oba przejścia idą po całej przestrzeni kluczy. Na dużej bazie dorzuć -i 0.1, żeby robiły przerwy między porcjami i nie obciążały serwera.

Statystyki komend

INFO commandstats

Ile razy każda komenda poszła i ile średnio zajęła (usec_per_call). Zwykle tu wychodzi, że to nie Redis jest wolny, tylko ktoś wali KEYS w pętli.

Wyzerowanie liczników przed pomiarem:

CONFIG RESETSTAT

redis-cli --scan --pattern 'KEY_PREFIX*' | xargs -r -n 500 redis-cli UNLINK

--scan chodzi po kluczach porcjami.

UNLINK — zwalnia w osobnym wątku, nie blokuje. -n 500 żeby nie odpalać procesu na każdy klucz z osobna, -r pomija wywołanie, jak nic nie znalazło.

Najpierw zobacz, co zostanie usunięte:

redis-cli --scan --pattern 'KEY_PREFIX*' | head

--scan przeszukuje tylko aktualny node, pod który jesteś podpięty (sprawdź –cluster call dla klastra)

Przed merge własnego brancha (na którym sam pracujesz) rób własny squash roboczych commitów:

git reset HEAD~x --soft

(soft trzyma pliki w indexie, nie trzeba ich potem ponownie zaznaczać do commita)

Potem rebase brancha na maina i push:

git rebase main
git push --force-with-lease

Jest to opcja lepsza niż squash przy merge, bo masz potem w przypadku chęci powrotu na brancha zgodność z remote

Daje to świetny porządek w repo i historii, ale minusem jest, że masz mniej commitów i zmienionych linii, co może być słabe jak trafisz na managera robiącego micromanagement i porównującego wydajność na podstawie repo