-
Notifications
You must be signed in to change notification settings - Fork 3.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
server,ui: CPU count metric is incorrect when using containers/orchestration/k8s #34988
Comments
|
@bdarnell reports separately:
It's likely a bug in our upstream @lunevalex @petermattis how do you propose to triage this? |
@piyush-singh @johnrk I also guess you'd need to review the priority of this together now. |
It's not just that the metric is incorrect, it's that GOMAXPROCS is set incorrectly. There was a weak attempt by me to adopt automaxprocs earlier in the year that I should revive. A mismatch between the GOMAXPROCS value and the number of cores as constrainted by cgroups can have disastrous consequences for performance. See #44880 and cockroachdb/docs#5922 |
Clarification after discussing with @ajwerner: |
50981: cli: add support for userfile upload CLI command r=adityamaru a=adityamaru This change adds a CLI command allowing users to upload local files to the user scoped file table ExternalStorage. The command `userfile upload` uses the existing COPY protocol (similar to `nodelocal upload`) to upload files and write them to the UserFileTableSystem. The UserFileTableSystem is backed by two SQL tables which are currently always created with `defaultdb.public.user` as the prefix of the qualified name. In the future we may allow users to specify the `db.schema` they wish to store their tables in. The command takes a source and destination path. The former is used to find the file contents locally, the latter is used to reference the file and its related metadata/payload in the SQL tables. Known limitations: - All destination paths must start with `/`, this is to help us disambiguate filepath from `db.schema` name when we allow users to specify that in the future. - Destination paths must not have a `..` in them. Since the UserFilTableSystem is not a "real" file system, storing SQL rows with filenames such as /test/../test.csv seems strange. We will work on enforcing a better naming scheme. Informs: #47211 Release note (cli change): Adds a userfile upload command that can be used to upload a file to the user scoped blob storage: `userfile upload source/file /destination/of/file` 51392: build/deploy: add GEOS libraries to CRDB Docker builds r=jlinder a=otan Now that we have the GEOS libraries being built, it's time we copy them into the right place in the Docker container such that users can import geospatial features out of the box. The bless release script will also copy these files over. Release note (general change): The Docker container that ships with CockroachDB now includes the GEOS library needed for geospatial functionality in `/usr/local/lib/cockroach` (which is the default location of where the cockroach binary looks for the GEOS libraries). 51443: opt: improve geo func costing r=otan a=mjibson Release note: None 51444: builtins: implement ST_Disjoint r=rytaft a=otan Resolves #48919. Release note (sql change): Implements the ST_Disjoint builtin for geometry types. 51471: cloud: Respect Kubernetes resource limits r=bobvawter a=bobvawter Detecting the number of available CPU cores and memory limits from within a container can be inaccurate. This change passes the CPU and memory limits used by the Kubernetes scheduler into the cockroach process. In the absense of a limits block (e.g. when using BestEffort QOS in a dev/staging environment), the scheduler will substitute the maximum value that is appropriate for the node on which the container is scheduled. This change can be applied retroactively to existing deployments and is not specific to a particular version of CockroachDB. The cockroach start command is broken onto multiple lines to improve readability. See also: #34988 Release note: None Co-authored-by: Aditya Maru <[email protected]> Co-authored-by: Oliver Tan <[email protected]> Co-authored-by: Matt Jibson <[email protected]> Co-authored-by: Bob Vawter <[email protected]>
@itsbilal we have this issue in the backlog; did your latest changes fix this? |
Yes - partly. CPU limits are now accounted for in charts and metrics. CPU requests are harder (if even possible) to account for in Cockroach, and cockroachdb/docs#9001 goes into why. |
Describe the problem
using Kubernetes on a server with 64 virtual CPUs and resource limits as below
Admin UI reports 64 CPUs instead of 4 CPUs.
To Reproduce
Using
CockroachDB 2.1.4
Kubernets 1.13.2
Expected behavior
is this expected behavior?
The text was updated successfully, but these errors were encountered: