Purged

Wikimedia infrastructure

Data centers

Networking

Global traffic routing

• Global traffic routing
• Caching overview
• DNS
• HTTPS
• HAProxy
• Varnish
• Apache Traffic Server
• Traffic cache hardware
• HTTP timeouts
• Purged
• MediaWiki HTTP cache headers
• Kafka HTTP purging
• URI path normalization
• Query string normalization
• Ncredir
• Acme-chief

MediaWiki

Multimedia

Data Engineering

Search

Data Persistence

Infra Foundations

Observability

Performance Team

[]

purged is a daemon running on all cache hosts that reads Kafka purge messages, parses them, and turns them into HTTP PURGE requests to be sent to the local ATS and Varnish daemons.

Detailed information about running purged instances can be found on this grafana dashboard.

The daemon is written in Golang, see the operations-software-purged repo.

Building the package

To target Debian Buster, build the package as follows on the build host (deneb at the time of this writing):

WIKIMEDIA=yes BACKPORTS=yes ARCH=amd64 DIST=buster GIT_PBUILDER_AUTOCONF=no gbp buildpackage -jauto -us -uc -sa --git-builder=git-pbuilder

Alerts

The details about which pages need to be purged come from Kafka: for this reason we monitor the amount of time since the last Kafka message received and alert if it is not within a certain threshold. Here's how the alert looks like:

Time elapsed since the last kafka event processed by purged on cp2041 is CRITICAL: cluster=cache_text instance=cp2041 job=purged site=codfw topic={codfw.resource-purge,eqiad.resource-purge} https://wikitech.wikimedia.org/wiki/Purged https://grafana.wikimedia.org/dashboard/db/purged?var-datasource=codfw+prometheus/ops&var-instance=cp2041

If this happens and nobody from Traffic is around to take a look, the best course of action is killing purged and checking the journal to see if it is being restarted properly by systemd:

$ sudo pkill -9 purged
$ sudo journalctl -u purged --since today
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Main process exited, code=killed, status=9/KILL
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Failed with result 'signal'.
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Consumed 2d 16h 43min 48.527s CPU time.
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Service RestartSec=100ms expired, scheduling restart.
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Scheduled restart job, restart counter is at 58.
Jun 29 08:57:05 cp2041 systemd[1]: Stopped Purger for ATS and Varnish.
Jun 29 08:57:05 cp2041 systemd[1]: purged.service: Consumed 2d 16h 43min 48.527s CPU time.
Jun 29 08:57:05 cp2041 systemd[1]: Started Purger for ATS and Varnish.
Jun 29 08:57:05 cp2041 purged[44684]: 2020/06/29 08:57:05 Listening for topics eqiad.resource-purge,codfw.resource-purge
Jun 29 08:57:05 cp2041 purged[44684]: 2020/06/29 08:57:05 Process purged started with 48 backend and 4 frontend workers. Metrics at :2112/metrics
Jun 29 08:57:05 cp2041 purged[44684]: 2020/06/29 08:57:05 Start consuming topics [eqiad.resource-purge codfw.resource-purge] from kafka
Jun 29 08:57:05 cp2041 purged[44684]: 2020/06/29 08:57:05 Reading from 239.128.0.112,239.128.0.115 with maximum datagram size 4096

Gather information for bug reports

purged CPU profile diagram

If purged seems to be misbehaving, data such as perf reports, callgraphs and go profiling can be useful to diagnose the issue.

One minute of perf data can be gathered on the host where purged is running with:

sudo timeout 60 perf record -p `pidof purged`
sudo perf report --stdio

Similarly, go profile information can be collected with:

curl http://localhost:2112/debug/pprof/profile?seconds=60 > cpuprof

Copy the file cpuprof to a system with go installed, and run the following command to get a detail of CPU usage to standard output

go tool pprof -top cpuprof

A PNG profile diagram can be created with:

go tool pprof -png cpuprof