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
v2.4.0 DB migration script corrupts saved studies over a certain size #2216
Comments
I test the DB migration using the following script. import optuna
N_PARAMS = 30
N_TRIALS = 1500
def objective(trial):
for i in range(N_PARAMS):
trial.suggest_float(f"x{i}", 0, 1)
return 1.
sampler = optuna.samplers.RandomSampler()
study = optuna.create_study(storage="sqlite:///test.db", study_name="test", sampler=sampler)
study.optimize(objective, n_trials=N_TRIALS) I didn't have any errors after the upgrade and |
I cannot share the code directly, but your snippet accomplishes essentially the same thing. You ran the study with v2.3.0 and then successfully updated the study using the optuna CLI for v2.4.0? If so, perhaps it's not related to total number of trials but rather related to the size of the DB file created. I ran
|
Yes, I did it. Do you have no error if you use my code snippet? If so, I suspect that it is an issue of your local environment. It may be one of the library you use. Is not so, it should be an issue of the DB migration script. For the reproducibility, please tell me the number of trials and the number of parameters. From the analysis results shared with you, it seems that trial parameters are dominant in the DB. |
Thank you for your response. I ran your script with v2.3.0 and then updated the db using the v2.4.0 cli (reproducing the original conditions) and the migration was successful:
The number of parameter was 34. The number of trials defined in the creation of the study was 1000. The optimization was running in a distributed environment with a remote file system providing the db for managing the trials. The study itself continued beyond 1000 trials (which was fine) and I stopped it manually at 1086. I was running multiple studies in parallel too (with a different study db, but same logic). The other study db, which was set for 1000 trials was stopped at number 946. This db file and the migration were successful. This could be related. I should have some time later to run a test which exceeds the initially specified number of trials and see if that is indeed the cause of the issue. |
Thank you. Then the failure of the DB migration may be due to the script.
That's reasonable. I look forward to the results of the investigation. |
After trying to reproduce locally with a modified version of your sample study script, I failed to be able to reproduce the issue. Tests I conducted:
Because of this, I'm currently of the opinion that the issue is likely specific given my particular distributed setup and my abuse of the sqlite db: NFS, running in parallel, read/write over a network connection, etc.- many places for the introduction of db conflicts. Additionally, I don't foresee any issues moving forward. I have migrated all of my optimization scripts over to 2.4.0 and for distributed systems, switched over to a more robust RDB cloud backend. My only suggestion might be a more intuitive log message with a link to the docu suggestions for the RDB configuration, but otherwise, I think this can be closed unless you deem further investigation necessary. |
Thank you for your careful and insightful reply.
Great! If you encounter any problems, please feel free to raise an issue.
Sounds good to me, but I don't have any concrete ideas to improve the log message. Do you have any idea? If you have one, I welcome you to send us a PR! |
Let me close this issue since this is addressed. |
After update to v2.4.0, the DB migration script for migrating table schema from study DB's <2.4.0 (
$ optuna storage upgrade --storage $STORAGE_URL
) corrupts sqlite DB's over a certain size (number of trials).Expected behavior
The migration/update to the table schema works fine for smaller tables, so I would expect it to work on larger tables as well. If not, perhaps a warning before it corrupts the db file.
Environment
Error messages, stack traces, or logs
Steps to reproduce
$ optuna storage upgrade --storage $STORAGE_URL
to update the study.db
file schemaoptuna.load_study(...)
The text was updated successfully, but these errors were encountered: