[opensuse-ja] SLES 10 SP1でのPostgreSQLの運用についての質問
小林健太郎と申します、よろしくお願いします。 opensuse-jaのMLなので、SLESのご質問をして良いか分からなかったの ですが、もし何か分かれば教えて頂ければと思います。 以下のような状況です。 SUSE Linux Enterprise Server 10 SP1がインストールしてある 環境で、PostgreSQLを利用しています。PostgreSQLのバージョンは、 最初はパッケージから8.1.9をインストールしていましたが、 今回ご相談する現象にはまり、最新の8.2.4をソースからコンパイルして インストールしました。結果、どちらのバージョンでも同じ現象が出ていま す。 起きている現象は、作成したDBに、6,500件のメインテーブル、 それに外部結合したい4,000件のテーブルが二つあります。 SQLでLEFT OUTER JOINを使って、メインのテーブルに２つ 繋げているSQLをかけると、レスポンスが15秒ぐらい返ってきません。 （結果は、6,500件返ってきます。） 外部結合しているので、SQLの問題も考えたのですが、RedHat ES3や CentOS4.4、Mac OS XなどでPostgreSQLのバージョンは違いますが、 同じDBを作って実行すると、すぐにレスポンスがあります。 PostgreSQLのメモリ割り当て関連ではないかと思っているのですが、 レスポンスがすぐにある環境で、特にshared_buffersの設定変更を していないのにこの結果でした。また、SLESの方のshared_buffersを 上げても全然変わりませんでした。 そうなると、OSに依存した何らかのメモリ割り当て関連等ではないかと 思ったのですが、そこで行き詰まってしまい、このMLに質問をさせて 頂きました。 ちなみに、ipcsの結果は、以下のような感じです。 sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 4194303 max total shared memory (pages) = 268435200 min seg size (bytes) = 1 sv:~ # ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x0052e2c1 32768 postgres 600 38076416 2 0x00000001 98305 root 600 655360 2 0x00000000 131074 gdm 600 196608 2 dest 0x00000000 163843 root 600 33554432 6 dest お知恵を頂ければ幸いです。よろしくお願いします。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。 ハズしているかもしれませんが.....
SUSE Linux Enterprise Server 10 SP1がインストールしてある 環境で、PostgreSQLを利用しています。PostgreSQLのバージョンは、
インストールしているサーバーに、raidカードは積んでいますか？ また、redhat CentOS のサーバーは、raidカードを積んでいますか？ もし、suseだけraidカードを積んでいるのであり、raid5 なんかに 設定している場合、elevetor オプションをいじくってみたらどうでしょう？ selectは通常速度、insert update が以上に遅い場合、この可能性も あるかもしれません。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 xeon-koyamaさん、ご意見ありがとうございます。 raidカード、およびraid構成は、SLESおよびredhatや CentOSの環境では積んでおりません。どれもCPU Pentium4、 Memory 512MB〜1GB、HDD 80GBそこそこのデスクトップPCに 検証用にセットアップしたものです。 opensuseでも同じ現象が起きるかどうか、10.2を ダウンロードしてみます。 On Mon, 23 Jul 2007 17:04:15 +0900, koyama wrote:
xeon-koyamaです。
ハズしているかもしれませんが.....
SUSE Linux Enterprise Server 10 SP1がインストールしてある 環境で、PostgreSQLを利用しています。PostgreSQLのバージョンは、
インストールしているサーバーに、raidカードは積んでいますか？
また、redhat CentOS のサーバーは、raidカードを積んでいますか？
もし、suseだけraidカードを積んでいるのであり、raid5 なんかに 設定している場合、elevetor オプションをいじくってみたらどうでしょう？
selectは通常速度、insert update が以上に遅い場合、この可能性も あるかもしれません。
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
07/07/23 に Kentarow Kobayashi さんは書きました:
小林健太郎と申します、よろしくお願いします。
opensuse-jaのMLなので、SLESのご質問をして良いか分からなかったの ですが、もし何か分かれば教えて頂ければと思います。 もし、急ぎだとか、仕事でということであれば、きちんとした サポートを受けて、そこにも(同じ平行的に)問い合わせを 行なった方が良いと思います。
以下のような状況です。
SUSE Linux Enterprise Server 10 SP1がインストールしてある 環境で、PostgreSQLを利用しています。PostgreSQLのバージョンは、 最初はパッケージから8.1.9をインストールしていましたが、 今回ご相談する現象にはまり、最新の8.2.4をソースからコンパイルして インストールしました。結果、どちらのバージョンでも同じ現象が出ていま す。
起きている現象は、作成したDBに、6,500件のメインテーブル、 それに外部結合したい4,000件のテーブルが二つあります。 SQLでLEFT OUTER JOINを使って、メインのテーブルに２つ 繋げているSQLをかけると、レスポンスが15秒ぐらい返ってきません。 （結果は、6,500件返ってきます。）
(1)6,500件のメインテーブル と 4,000件のテーブルを内部結合したとき---テストデータ (2)6,500件のメインテーブル と 4,000件のテーブルを外部結合したとき を比較するのが良いと思います。(考え方として。) (1)で、期待する動きをするなら、PostgreSQLの問題ではないと思います。 ＃ここで、単独(結合しない)のクエリーには帰ってきているのですよね。 (2)が、おかしいなら、外部結合して正常に動かす為の前提条件に問題が あるはずです。 ＃RedHat ES3やCentOS4.4、Mac OS Xなどは、それらの前提条件が ＃うまくいっているから動くのではないでしょうか。 (1), (2)がともにおかしいなら(期待どおりに動いてくれない) --- 外部結合以前の問題。 SLES 10PS1, やPostgreSQL 8.1.9, PostgreSQL 8.2.4 のＯＳのチューニングやPostgreSQLのチューニングに問題が あると考えられるのでそこをデバッグするべきだと思います。 ＃まずは、内部に対するクエリーと外部に対するクエリー ＃を比較して、問題の切り分けをすることが大切かと。(クエリーの件数に関係なく) ＃(いきなり、本番環境で出来る／出来ない をやってもデバックできないかと。) あと、このケースだと、何がしかのログ(syslogなり、PostgreSQLのログ) なりが出ているはずで... まずは、ログを見てみるのが問題解決の近道かと思います。 ＃どこまで、正しく動作して、どこから正しく動作していないかを ＃切り分けていくこと大切だと思います。 --- takezou061228 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 takezou061228@gmail.comさん、ご意見ありがとうございます。 On Mon, 23 Jul 2007 18:22:47 +0900, takezou wrote:
opensuse-jaのMLなので、SLESのご質問をして良いか分からなかったの ですが、もし何か分かれば教えて頂ければと思います。 もし、急ぎだとか、仕事でということであれば、きちんとした サポートを受けて、そこにも(同じ平行的に)問い合わせを 行なった方が良いと思います。
はい、おっしゃられる通りです。現状としては、サポート無しでSLESの ライセンス購入が行なわれていて、Novellのサポートを受けるには、 もう一ライセンスとあわせてCareサポートを購入する必要があるので、 その手続きの前に、もし何か同様の事例等があればと思って、MLの過去ログ なども見たのですが、見つける事ができず、質問させて頂きました。
起きている現象は、作成したDBに、6,500件のメインテーブル、 それに外部結合したい4,000件のテーブルが二つあります。 SQLでLEFT OUTER JOINを使って、メインのテーブルに２つ 繋げているSQLをかけると、レスポンスが15秒ぐらい返ってきません。 （結果は、6,500件返ってきます。）
(1)6,500件のメインテーブル と 4,000件のテーブルを内部結合したと き---テストデータ (2)6,500件のメインテーブル と 4,000件のテーブルを外部結合したとき を比較するのが良いと思います。(考え方として。)
(1)で、期待する動きをするなら、PostgreSQLの問題ではないと思います。 ＃ここで、単独(結合しない)のクエリーには帰ってきているのですよね。
はい、単独および内部結合でのクエリーは期待のレスポンスで返ってきます。 外部結合しないクエリーは、差し当たり期待通りのレスポンスで返ってきてい て、 外部結合したとたんに今回の現象が起きました。
(2)が、おかしいなら、外部結合して正常に動かす為の前提条件に問題が あるはずです。 ＃RedHat ES3やCentOS4.4、Mac OS Xなどは、それらの前提条件が ＃うまくいっているから動くのではないでしょうか。
正直なところは、この前提条件がPostgreSQLではなくSUSE Linuxとして 何かあるのではと思ったしだいです。問題のSQLを実行すると、 CPUが100%にずっといったまま作業をして返ってくるという挙動をするので、 PostgreSQLのデーモンを動かしているpostgresユーザに、何か十分な メモリ割り当て等をしなければいけないのではと考えました。
あと、このケースだと、何がしかのログ(syslogなり、PostgreSQLのログ) なりが出ているはずで... まずは、ログを見てみるのが問題解決の近道かと思います。 ＃どこまで、正しく動作して、どこから正しく動作していないかを ＃切り分けていくこと大切だと思います。
切り分けについては、おっしゃられている通りだと思います。 標準の状態では、ログとして何も出ていなかったので、もう少し詳しく 出るようにしてみます。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
07/07/23 に Kentarow Kobayashi さんは書きました:
小林健太郎です。
[...]
(2)が、おかしいなら、外部結合して正常に動かす為の前提条件に問題が あるはずです。 ＃RedHat ES3やCentOS4.4、Mac OS Xなどは、それらの前提条件が ＃うまくいっているから動くのではないでしょうか。
正直なところは、この前提条件がPostgreSQLではなくSUSE Linuxとして 何かあるのではと思ったしだいです。問題のSQLを実行すると、 CPUが100%にずっといったまま作業をして返ってくるという挙動をするので、 PostgreSQLのデーモンを動かしているpostgresユーザに、何か十分な メモリ割り当て等をしなければいけないのではと考えました。 RedHat ES3やCentOS4.4、Mac OS Xなどで動作確認を することは無駄ではないと思いますが、それで動いたから、 SLES SP1 でもすぐに動く(動かないといけない)というふうに 考えるのは良くないと思います。
データベースが正しく動いていることを簡単な(テスト)テーブルなどで １つづつ確認しながら、切り分けていくことが必要だと思います。 ・6,500件のメインテーブルと同じようなテストテーブル(1件分の大きさ)に対してクエリーだす。 ・4,000件のテーブルと同じようなテストテーブル(1件分の大きさ)に対してクエリーだす。 ・上記ようなテーブルで、内部結合するようなクエリー(1件)だす。 ・上記ようなテーブルで、外部結合するようなクエリー(1件)だす。 ＃ここまでだと、メモリ割り当てが問題にならないと思います。(まずは、1件分のクエリーで。) ＃Defaultの設定なりで動くのでは？ ・ ・ ・ 一般論として、ＤＢを動かすには、以下のような項目があると思います。 ・データベースのインストール(セットアップ) ・ＯＳなどチューニング(共有メモリなど) ・ＤＢ自体の設計(テーブルのデザイン) ・ＤＢのミドルウェアーの設定など ・ネットワークの設定(SQLサーバ、ＳＱＬクライアントのネットワーク設定) ＃SLES SP1の(default)設定なりに、問題が無いかというとそうでもないかも ＃しれません。 ただし、そこらあたりの切り分けがご自身できないなら ＃SLES SP1 --- ノベルなりとサポート契約 ＃PostgreSQL --- SRAなりとサポート契約(多分やっていると思いますけど...) ＃というのが良いと思います。 ネットワーク越し(localhostであっても)に、外部のテーブルと外部結合 するなら、ネットワーク(OS)の設定の影響を受けると思います。 ＃私の場合、Webアプリ(CMS)なんかで、バックエンドにMysql なんかがあるときは、 ＃手動でクエリーだして、Mysqlの動作確認するなどしながらCMSの動作確認を ＃進めていきます。(最初から、ＤＢの配置をどうしょうかなども考えます。大体localhostですけど)
あと、このケースだと、何がしかのログ(syslogなり、PostgreSQLのログ) なりが出ているはずで... まずは、ログを見てみるのが問題解決の近道かと思います。 ＃どこまで、正しく動作して、どこから正しく動作していないかを ＃切り分けていくこと大切だと思います。
切り分けについては、おっしゃられている通りだと思います。 標準の状態では、ログとして何も出ていなかったので、もう少し詳しく 出るようにしてみます。 くりかえすようですが、データベースがどのよう動いているかを 検証するために、標準の状態ではログがなにも出ないなら 出すようにして調べる。 ＃基本的な問題解決へのアプローチが大切なのではないでしょうか。
--- takezou061228 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 takezouさん、ご意見ありがとうございます。
RedHat ES3やCentOS4.4、Mac OS Xなどで動作確認を することは無駄ではないと思いますが、それで動いたから、 SLES SP1 でもすぐに動く(動かないといけない)というふうに 考えるのは良くないと思います。
データベースが正しく動いていることを簡単な(テスト)テーブルなどで １つづつ確認しながら、切り分けていくことが必要だと思います。
頂いたご意見は、ただただごもっともで、データベースが簡単なSQLなどでは 動く検証をしていたのですが、そこで外部結合でとたんに遅くなったので 原因の切り分けをしていました。その中で、行き詰まり、とりあえず別環境で の 結果はどうだろうか？というような事も調べていたしだいです。
くりかえすようですが、データベースがどのよう動いているかを 検証するために、標準の状態ではログがなにも出ないなら 出すようにして調べる。 ＃基本的な問題解決へのアプローチが大切なのではないでしょうか。
ログというのとは少し違いますが、SQLの実行時にEXPLAIN ANALYZEを付けて 実行してみると、差があるので、そこにヒントがありそうなので、 そこを詰めてみたいと思います。 そうなると、OSというよりも何かPostgreSQLの設定等の問題なのかもしれませ ん。 何か、分かりましたら改めて、ご連絡したいと思います。 ありがとうございます。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。 関係ないとは思いますが、気になった所
ちなみに、ipcsの結果は、以下のような感じです。
sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 4194303 max total shared memory (pages) = 268435200 ↑ ここの所 min seg size (bytes) = 1
私の場合、以下のようになります。 ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 131072 <--ここの所 min seg size (bytes) = 1 ちなみに、sysctl.conf では、 kernel.shmmax=536870912 kernel.shmall=131072 共有メモリ設定 512Mにしています。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 xeon-koyamaさん、ご意見ありがとうございます。 sysctl.confは最初は何も設定していなかったのですが、ひとまず
kernel.shmmax=536870912 kernel.shmall=131072 にして、念のため再起動したのですが、結果は以下の通りでした。
sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 268435200 min seg size (bytes) = 1 sv:~ # cat /proc/sys/kernel/shmall 268435200 sv:~ # cat /proc/sys/kernel/shmmax 536870912 sv:~ # cat /etc/sysctl.conf # 中略 # shared memory kernel.shmmax=536870912 kernel.shmall=131072 shmallが全然変化してくれませんでした。何かがおかしい ということですよね。SQLの実行結果も大きな変化はありませんでした。 切り分けとして、大きすぎるとは思うのですが、SP1ではないSLES 10の 環境も用意してみようかと思い始めています。 SQLを実行時にEXPLAIN ANALYZEを付けて、差を見たりして いるのですが、初期化コストがすごく違って出ている(遅い方がすごく小さ い） ので、その辺りにヒントがないかとは思って、調査を続けています。 On Mon, 23 Jul 2007 20:49:30 +0900, koyama wrote:
xeon-koyamaです。
関係ないとは思いますが、気になった所
ちなみに、ipcsの結果は、以下のような感じです。
sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 4194303 max total shared memory (pages) = 268435200 ↑ ここの所 min seg size (bytes) = 1
私の場合、以下のようになります。
------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 131072 <--ここの所 min seg size (bytes) = 1
ちなみに、sysctl.conf では、
kernel.shmmax=536870912 kernel.shmall=131072
共有メモリ設定 512Mにしています。
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 すいません、一点訂正です。shmallが変化しなかったのは、 powertweakdが立ち上がっていたからでした。落として、 再度確認したところ、変化はいたしました。 sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 131072 min seg size (bytes) = 1 sv:~ # cat /proc/sys/kernel/shmall 131072 実行したSQLには、変化は生じませんでした。 以上です。 On Tue, 24 Jul 2007 11:28:13 +0900, Kentarow Kobayashi wrote:
小林健太郎です。
xeon-koyamaさん、ご意見ありがとうございます。 sysctl.confは最初は何も設定していなかったのですが、ひとまず
kernel.shmmax=536870912 kernel.shmall=131072 にして、念のため再起動したのですが、結果は以下の通りでした。
sv:~ # ipcs -ml
------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 268435200 min seg size (bytes) = 1
sv:~ # cat /proc/sys/kernel/shmall 268435200 sv:~ # cat /proc/sys/kernel/shmmax 536870912
sv:~ # cat /etc/sysctl.conf # 中略 # shared memory kernel.shmmax=536870912 kernel.shmall=131072
shmallが全然変化してくれませんでした。何かがおかしい ということですよね。SQLの実行結果も大きな変化はありませんでした。
切り分けとして、大きすぎるとは思うのですが、SP1ではないSLES 10の 環境も用意してみようかと思い始めています。
SQLを実行時にEXPLAIN ANALYZEを付けて、差を見たりして いるのですが、初期化コストがすごく違って出ている(遅い方がすごく小さ い） ので、その辺りにヒントがないかとは思って、調査を続けています。
On Mon, 23 Jul 2007 20:49:30 +0900, koyama wrote:
xeon-koyamaです。
関係ないとは思いますが、気になった所
ちなみに、ipcsの結果は、以下のような感じです。
sv:~ # ipcs -ml ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 4194303 max total shared memory (pages) = 268435200 ↑ ここの所 min seg size (bytes) = 1
私の場合、以下のようになります。
------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 131072 <--ここの所 min seg size (bytes) = 1
ちなみに、sysctl.conf では、
kernel.shmmax=536870912 kernel.shmall=131072
共有メモリ設定 512Mにしています。
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。
sv:~ # ipcs -ml
------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 524288 max total shared memory (pages) = 131072 min seg size (bytes) = 1
同じになりましたね。 私の場合、SUSE提供のpostgres関係は全て削除してつかっています。 特に、IPAのフォントを入れると grass--postgres となるので、 それらも根こそぎ削除して使っています。 （フォントだけ、再配布して欲しい......） その上で、postgresをコンパイルして使っています。 後は、takezou さんのおっしゃるように、postgresql.conf の パラメータを変更して見てはどうでしょう。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
小林健太郎です。 xeon-koyamaさん、ご意見ありがとうございます。 別メールにも書かせて頂きましたが、調査については、もう少しPostgreSQLの 中身を中心に行ないたいと思います。 ただ、頂いた文章に一つ知らない事があったので、教えて頂ければ幸いです。
私の場合、SUSE提供のpostgres関係は全て削除してつかっています。 特に、IPAのフォントを入れると grass--postgres となるので、 それらも根こそぎ削除して使っています。 （フォントだけ、再配布して欲しい......） その上で、postgresをコンパイルして使っています。
この、grass--postgresというのは、どういう状態なのでしょうか？ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。
この、grass--postgresというのは、どういう状態なのでしょうか？
grassというのは、grassパッケージ（地図のようなもの？） postgresというのは、postgreslibパッケージ(suseのpostgres ライブラリ） を示しています。 判りにくかったですね。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
今井です。 スレッドの流れからちょっとそれますが....。 Wednesday 25 July 2007 01:56:15 に koyama さんは書きました:
私の場合、SUSE提供のpostgres関係は全て削除してつかっています。 特に、IPAのフォントを入れると grass--postgres となるので、 それらも根こそぎ削除して使っています。 （フォントだけ、再配布して欲しい......）
IPAフォントの配付条件でフォント単独の配付を認めてないので、 無理じゃないのかなと...。 大元の配付元(grassの場合だけど)のサイトでもその辺り書いて ありますが....。 http://www.grass-japan.org/FOSS4G/license-ipafonts.eucjp.htm grassと同梱の時のみフォントの再配布しても良い事になってますから。 そもそもgrassが入ってると苦になる/苦にする様な事って何かあるのかなとい う事なんですけども...。 (HDDのリソースはちょっと消費しますけど)例えばevolution-data-serverとか 私にとっては無用な長物なんだけどパッケージの依存関係でインストールされた挙 句、CPUやメモリリソースまで無駄に消費される様な事にはなってないですし....。 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 今井 優 mail: maimai@coral.ocn.ne.jp web: http://www10.ocn.ne.jp/~masimai/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。
IPAフォントの配付条件でフォント単独の配付を認めてないので、 無理じゃないのかなと...。 grassと同梱の時のみフォントの再配布しても良い事になってますから。
そうですか...残念です。
そもそもgrassが入ってると苦になる/苦にする様な事って何かあるのかなとい う事なんですけども...。
イヤ、grassだけなら、単にわずかなディスク消費だけなんで問題ないのですが、 postgresのライブラリが依存関係にありまして、postgresを ソースコンパイルして入れる場合に、これが問題になると思ってます。 それで、(IPA + grass + postgresライブラリ)を削除して使っています。 OpenOfficeも同じ理由で、SUSE添付のjdkとの依存関係があるので、 別途JDKを入れる場合は、これもごっそり、削除です。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
こんにちは
イヤ、grassだけなら、単にわずかなディスク消費だけなんで問題ないのですが、 postgresのライブラリが依存関係にありまして、postgresを ソースコンパイルして入れる場合に、これが問題になると思ってます。 それで、(IPA + grass + postgresライブラリ)を削除して使っています。
grassが余計なら、Openprintと同梱も選択出来ますよ Naono --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
xeon-koyamaです。 A.Naono さん ご返答ありがとうございます。
grassが余計なら、Openprintと同梱も選択出来ますよ
そうなんですよね。ubuntu なんかだと Openprint に IPAフォント がくっついて来るようですね。 個人的には、持っているprinterが全てHP製品なんで、こっちの方がありがたい です。 IPAは税金使って開発しているのだから、作成するのであれば、 Linuxで一番ないもので、みんなが困っているものであるフォントを 最初に作成して、配布してくれる方がありがたいと感じます。 勝手な推測ですが、多くの方が、必要なライブラリとして grass < IPAフォント だと感じているように思います。 --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-ja+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ja+help@opensuse.org
participants (5)
-
A.Naono -
Kentarow Kobayashi -
koyama -
Masaru Imai -
takezou