We're looking at CPU bandwidth control via CFS:
Program does number of iterations, in each iteration we burn CPU in small chunks until we get 5ms of real time spent. On each iteration we also print how much
| -- show running queries (pre 9.2) | |
| SELECT procpid, age(clock_timestamp(), query_start), usename, current_query | |
| FROM pg_stat_activity | |
| WHERE current_query != '<IDLE>' AND current_query NOT ILIKE '%pg_stat_activity%' | |
| ORDER BY query_start desc; | |
| -- show running queries (9.2) | |
| SELECT pid, age(clock_timestamp(), query_start), usename, query | |
| FROM pg_stat_activity | |
| WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%' |
We're looking at CPU bandwidth control via CFS:
Program does number of iterations, in each iteration we burn CPU in small chunks until we get 5ms of real time spent. On each iteration we also print how much
| #!/usr/bin/python | |
| # -*- coding: utf-8 -*- | |
| import argparse | |
| import sys | |
| import boto3 | |
| from select_runner import * |
If you're encountering ping github.com failing inside WSL with a Temporary failure in name resolution, you're not alone — this has been a long-standing issue, especially when using VPNs or corporate networks.
This issue is now fixed robustly with DNS tunneling, which preserves dynamic DNS behavior and avoids limitations like WSL’s former hard cap of 3 DNS servers in /etc/resolv.conf.
DNS tunneling is enabled by default in WSL version 2.2.1 and later, meaning that if you're still seeing DNS resolution issues, the first and most effective fix is simply to upgrade WSL. Upgrading WSL updates the WSL platform itself, but does not affect your installed Linux distributions, apps, or files.
To upgrade WSL, follow these steps,