443979 - talos collects memory information on mac in KB, on linux/win in Bytes

Status: RESOLVED FIXED

(Release Engineering :: General, defect)

Description

[alice nodelman [:alice] [:anode]]

Should standardize on bytes.  This requires:

- one very minor code change to talos
- fixing all the current values collected for mac talos machines (multiply by 1024) while the tree is closed
- re-opening the tree with the new talos code checked in

Comment 1

[alice nodelman [:alice] [:anode]]

Attachment: [Checked in]have mac collect memory information in bytes

Mac collects information about memory footprint through ps which defaults to Kb.  This simply takes those values and multiplies by 1024 to convert to bytes.

Comment 2

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 328556 [details] [diff] [review]
[Checked in]have mac collect memory information in bytes

I dug through the ps manpage looking for an option to do this in cmanager_mac.py and vsz and rss seem to return kb only.

Do you really want floats for this value?

Comment 3

[alice nodelman [:alice] [:anode]]

I believe that this query should update all of the currently stored memory information on mac machines and multiplies by 1024:

update dataset_values set value = value * 1024 where dataset_id in ( select id from dataset_info where (machine like "%pmac%" or machine like "%pleopard%" or machine like "%ptiger%") and (test like "%RSS" or test like "%Private%"));

This is sort of a risky move, so we'd want to stop all of the talos boxes (or make the graph server inaccessible), do the update, push the talos change, re-open the graph server/re-start the talos slaves and then check to see if new memory numbers make sense when plotted against old memory numbers.

None of this is particularly complicated, but it would have to be done careful to ensure that we don't corrupt any data.

Comment 4

[alice nodelman [:alice] [:anode]]

Attachment: sql query to update all stored mac memory info to bytes

Comment 5

[Mark Smith [:xb95]]

Thanks for reminding me about this.  I was doing analysis to try to determine how long this query would take to run, and was unable to get it to complete - at all - as a SELECT.

MySQL doesn't handle subselects very well, not on tables with hundreds of millions of rows (even though dataset_info is only 1.5 million).  Is there any way we can refactor this in the form of a temporary table created manually and maybe a script?

I.e., have a script pull out the subselect data, and then iterate over the main data one value at a time and do the update.

(Did you run this against your local database?  Did it work okay there?)

Comment 6

[alice nodelman [:alice] [:anode]]

I'll admit to attempting to run this on graphs-stage and getting bored and killing it.  We've probably hit the limits of my mysql skillz, so I'd by happy for any pointers.

Comment 7

[Chris Cooper [:coop] (he/him)]

It ran here, and did complete, but my test data only has 7561 rows in the subselect. As Mark says, you may have to two step this.

Comment 8

[alice nodelman [:alice] [:anode]]

Mark - any chance that this would run to completion in a reasonable amount of time now that we've cleaned out all the old crufty data from the db?

Comment 9

[Mark Smith [:xb95]]

Okay, I got this done.  I had to do it in a different fashion and not use the subselect, but it's done now.  Please let me know if you see any weirdness.

If there is a problem I can revert it, I backed up the data I changed.

Comment 10

[alice nodelman [:alice] [:anode]]

We need to get that reverted as it needs to land with a matching patch to talos to ensure that all future data is sent using bytes.

Also, I'm not sure if you're query worked or not as the data still seems to be in KB for graphs that should have been affected.

Comment 11

[Mark Smith [:xb95]]

Revert is running.

Comment 12

[alice nodelman [:alice] [:anode]]

Comment on attachment 328556 [details] [diff] [review]
[Checked in]have mac collect memory information in bytes

Checking in cmanager_mac.py;
/cvsroot/mozilla/testing/performance/talos/cmanager_mac.py,v  <--  cmanager_mac.py
new revision: 1.3; previous revision: 1.2
done